Co to jest ROS 2?

ROS 2 to środowisko programistyczne dla robotyki, które łączy komunikację rozproszoną, mechanizmy czasu rzeczywistego i wygodne budowanie aplikacji sterujących robotami. W praktyce rozwiązuje problemy, z którymi ROS 1 radził sobie gorzej, zwłaszcza przy większej liczbie węzłów i bardziej wymagającej komunikacji. Jeśli chcesz szybko zrozumieć, do czego służy ROS 2 i czy nadaje się do Twojego projektu, przeczytaj dalej.

Najważniejsze informacje z tego artykułu:

• ROS 2 jest środowiskiem do tworzenia oprogramowania robotycznego.
• Działa w architekturze peer-to-peer opartej na DDS.
• Ułatwia sterowanie robotami, czujnikami i zadaniami automatyki.
• Wspiera C++, Pythona i Rust, a także systemy Linux, Windows i macOS.
• Wprowadza QoS, lifecycle nodes i lepsze wsparcie dla pracy rozproszonej.

Co to jest ROS 2?

ROS 2, czyli Robot Operating System 2, to middleware robotyczny i ekosystem narzędzi do budowy oprogramowania dla robotów. Nie jest klasycznym systemem operacyjnym. Pełni rolę warstwy pośredniej między kodem aplikacji a sprzętem, dzięki czemu porządkuje komunikację, uruchamianie procesów, definicje interfejsów i współpracę wielu modułów.

W praktyce ROS 2 służy do tworzenia systemów, które odbierają dane z czujników, przetwarzają je i wysyłają polecenia do elementów wykonawczych, takich jak napędy, chwytaki czy układy sterowania. Z tego powodu dobrze sprawdza się w robotach mobilnych, manipulatorach, systemach wizyjnych, autonomicznych pojazdach i symulacjach.

Najprościej ująć to tak: ROS 2 daje gotowy sposób podziału projektu na małe, współpracujące ze sobą części. Każda z nich realizuje konkretne zadanie, a cały system pozostaje czytelny nawet wtedy, gdy projekt zaczyna szybko rosnąć. I właśnie tu ROS 2 wygrywa z prostym, monolitycznym kodem, który początkowo wydaje się wygodny, a później zamienia się w kosztowny chaos.

ROS 2 nie dostarcza gotowego robota ani uniwersalnego algorytmu sterowania. Dostarcza infrastrukturę, na której buduje się własną logikę: nawigację, percepcję, planowanie ruchu, bezpieczeństwo funkcjonalne czy integrację z elektroniką.

Jak ROS 2 porządkuje pracę nad robotem?

ROS 2 organizuje system w węzły, czyli osobne procesy lub komponenty odpowiedzialne za pojedyncze funkcje. Jeden węzeł odczytuje kamerę, drugi estymuje pozycję, trzeci planuje trajektorię, a kolejny steruje napędami. Taki podział upraszcza rozwój projektu, bo łatwiej testować, wymieniać i diagnozować pojedyncze elementy.

W bardziej złożonych wdrożeniach pojawiają się też composite nodes, czyli złożone komponenty traktowane jak czarne skrzynki z własnym API. Wewnętrzne węzły współdzielą wtedy zasoby i mogą synchronizować stany cyklu życia, co ogranicza narzut komunikacyjny i porządkuje architekturę.

W systemie masz trzy podstawowe mechanizmy wymiany danych:

• Tematy – do ciągłego przesyłania danych, takich jak obraz, odczyt czujnika czy pozycja robota.
• Usługi – do krótkich zapytań i odpowiedzi, gdy potrzebujesz pojedynczej operacji.
• Akcje – do zadań długotrwałych, w których chcesz śledzić postęp, na przykład podczas nawigacji.

Taki model daje porządek od pierwszego dnia pracy. Z mojego doświadczenia właśnie to najszybciej odczuwa zespół: logika aplikacji, warstwa sprzętowa i komunikacja przestają być splątane w jednym miejscu.

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

Najważniejsza zmiana dotyczy architektury komunikacji. ROS 1 opierał się na centralnym masterze, czyli pojedynczym punkcie koordynacji. ROS 2 zastąpił ten model architekturą peer-to-peer opartą na DDS, co usuwa pojedynczy punkt awarii i poprawia skalowalność w systemach rozproszonych.

W praktyce różnica jest odczuwalna od razu. Gdy system obejmuje wiele komputerów, robotów, czujników i procesów działających równolegle, ROS 2 lepiej radzi sobie z wykrywaniem uczestników sieci, kontrolą parametrów transmisji i stabilnością pod obciążeniem. Badania dotyczące bezpieczeństwa aplikacji robotów wykorzystujących ROS opisywały tę rodzinę narzędzi jako standard de facto w robotyce, a rozwój ROS 2 skupił się właśnie na wydajności, niezawodności i bezpieczeństwie oprogramowania.

Różnice między ROS 1 i ROS 2:

ROS 2 wprowadził też lifecycle nodes, czyli węzły z kontrolowanym cyklem życia. Mogą przechodzić przez stany unconfigured, inactive, active i finalized, a programista precyzyjnie kontroluje inicjalizację zasobów, aktywację i zamykanie komponentu. W robotyce przemysłowej i we flotach robotów to duże ułatwienie, bo system zachowuje się bardziej przewidywalnie.

Zmieniło się również budowanie pakietów. Zamiast catkin pojawił się ament, a do pracy z workspace używa się colcon. To porządkuje projekty wielojęzyczne i ułatwia rozwój większych repozytoriów.

Kiedy migracja do ROS 2 ma sens?

Migracja ma sens wtedy, gdy projekt ma przed sobą dłuższy rozwój, ma pracować w sieci rozproszonej albo musi spełniać wyższe wymagania dotyczące stabilności i bezpieczeństwa. Dotyczy to szczególnie systemów produkcyjnych, robotów współpracujących, platform autonomicznych i rozwiązań rozwijanych przez kilka lat.

Najczęstsze powody przejścia na ROS 2 to:

• Potrzeba pracy na wielu komputerach lub wielu robotach.
• Wymóg lepszego zarządzania opóźnieniami i niezawodnością.
• Chęć użycia mechanizmów bezpieczeństwa.
• Plan rozwoju projektu na kolejne lata.

Przy małym, zamkniętym projekcie opartym na starym kodzie migracja nie zawsze się opłaca. Czasem koszt przeniesienia bibliotek, sterowników i testów integracyjnych zjada cały zysk. To nie jest porażka techniczna, tylko zwykła kalkulacja inżynierska.

Jak działa DDS w ROS 2?

DDS, czyli Data Distribution Service, stanowi warstwę komunikacyjną ROS 2. To standard wymiany danych w systemach rozproszonych, który odpowiada za odkrywanie uczestników w sieci, publikowanie i subskrypcję wiadomości oraz egzekwowanie polityk QoS, czyli jakości usług transmisji.

Dzięki DDS węzły komunikują się bez centralnego mastera, a parametry transmisji da się dopasować do zastosowania. Inne ustawienia sprawdzą się dla obrazu z kamery, inne dla poleceń napędów, a jeszcze inne dla komunikatów bezpieczeństwa. To nie jest detal konfiguracyjny. To część architektury sterowania.

Najważniejsze polityki QoS, które warto znać:

• Reliable – gdy wiadomość musi dotrzeć, nawet kosztem opóźnienia.
• Best-effort – gdy ważniejsza jest szybkość niż pełna gwarancja dostarczenia.
• Transient-local – gdy nowy odbiorca ma dostać ostatnią zapamiętaną wiadomość.
• Keep-last – gdy chcesz przechować ograniczoną liczbę ostatnich wiadomości.
• Keep-all – gdy system ma zachować całą historię danych, o ile pozwalają zasoby.

ROS 2 korzysta z wielu mechanizmów transportu, między innymi UDP, TCP i pamięci współdzielonej. W komunikacji wewnątrz procesu dostępne są optymalizacje ograniczające kopiowanie danych, na przykład transport zero-copy oparty na współdzieleniu wskaźników. To obniża narzut i zmniejsza opóźnienia w pętlach sterowania.

Domyślne implementacje DDS, takie jak Fast DDS, wspierają scenariusze soft real-time. W benchmarkach pętli typu komenda silnika–sprzężenie zwrotne z czujnika właśnie dobór QoS i sposób transportu mocno wpływają na latencję oraz jitter, czyli wahania opóźnień. ROS 1 radził sobie z tym wyraźnie słabiej przy większych topologiach i słabszych łączach.

ROS 2 oferuje też zintegrowane statystyki wiadomości dla subskrypcji. System potrafi mierzyć średnią, minimum, maksimum, odchylenie standardowe oraz liczbę próbek dla wieku wiadomości i okresu ich odbierania, a obliczenia wykonuje w oknie ruchomym. To praktyczne narzędzie diagnostyczne, bo pozwala wychwycić niestabilność transmisji bez budowania własnej warstwy pomiarowej.

Dlaczego QoS ma znaczenie w robotyce?

QoS decyduje o tym, jak zachowuje się komunikacja pod obciążeniem. W robotyce to bezpośrednio wpływa na przewidywalność sterowania, świeżość danych z czujników i stabilność całego układu.

Dla manipulatora ważna bywa deterministyczna transmisja i niski jitter. Dla obrazu z kamery lub lidaru pojedyncza utracona próbka często nie stanowi problemu, za to opóźnienie już tak. W systemach bezpieczeństwa liczy się ciągłość i kontrola stanu kanału komunikacyjnego. Dlatego przypadkowe ustawienie QoS szybko mści się poza laboratorium, zwłaszcza gdy Wi‑Fi zaczyna gubić pakiety dokładnie wtedy, gdy nikt tego nie potrzebuje.

Wskazówka: zaczynaj od domyślnych ustawień QoS, a potem dostosuj je do tempa publikacji, dopuszczalnych opóźnień i charakteru danych. Dla sterowania, telemetrii i wizji zwykle nie sprawdza się ten sam profil.

Przy ocenie jakości transmisji pomagają metryki. W systemach komunikacyjnych analizuje się latencję, jitter, liczbę utraconych wiadomości czy rozkład czasów dostarczenia. To podobna logika jak w innych dziedzinach inżynierii danych: sama obserwacja jednej próbki niewiele mówi. Nawet w badaniach kohortowych współczynnik ryzyka relatywnego poniżej 3, szczególnie poniżej 2, uznaje się za mało wiarygodny statystycznie bez mocnego kontekstu. W robotyce pojedynczy pomiar też potrafi oszukać. Dopiero seria pomiarów i analiza rozrzutu pokazują, czy system naprawdę pracuje stabilnie.

Podobnie działa ocena dopasowania modeli w analizie danych, gdzie wykorzystuje się współczynnik determinacji R2 czy średni kwadrat reszt RMS. W ROS 2 te konkretne wskaźniki nie służą do oceny samej komunikacji, ale zasada pozostaje identyczna: jakość systemu ocenia się na podstawie mierzalnych parametrów, a nie intuicji.

Jakie języki i narzędzia wspiera ROS 2?

ROS 2 wspiera kilka języków programowania, ale w praktyce dominują C++ i Python. C++ daje większą kontrolę nad pamięcią, czasem wykonania i wydajnością. Python przyspiesza prototypowanie, integrację bibliotek oraz testowanie logiki wysokiego poziomu.

W ekosystemie pojawia się też Rust, szczególnie tam, gdzie zespół szuka większego bezpieczeństwa pamięciowego. Nadal jest to jednak mniej powszechne rozwiązanie niż C++ i Python. Interfejsy wiadomości, usług i akcji definiuje się oddzielnie w języku opisu interfejsów, co porządkuje komunikację między pakietami i ułatwia wiązania wielojęzyczne.

Główne narzędzia w ekosystemie ROS 2:

• Colcon – do budowania workspace’ów i pakietów.
• Ament – do organizacji systemu budowania.
• Rclcpp – biblioteka klienta dla C++.
• Rclpy – biblioteka klienta dla Pythona.
• SROS2 – do zabezpieczania komunikacji.

Warto znać jeszcze kilka pojęć. IDL służy do definiowania interfejsów, rmw odpowiada za warstwę pośrednią między ROS 2 a implementacją DDS, a SROS2 bazuje na DDS Security i obsługuje uwierzytelnianie, szyfrowanie oraz kontrolę dostępu. W zastosowaniach przemysłowych to już nie dodatek, tylko realny element architektury.

Z mojego punktu widzenia najwygodniejszy start daje podział pracy: Python do szybkiego tworzenia logiki, C++ tam, gdzie liczy się wydajność, deterministyczne zachowanie i integracja z bardziej wymagającym kodem.

Jakie są pierwsze kroki z ROS 2?

Na początku najlepiej zbudować minimalny, działający układ i dopiero potem rozszerzać projekt. To oszczędza sporo frustracji, bo ROS 2 ma rozbudowany ekosystem, a nadmiar narzędzi na starcie łatwo przytłacza.

Kroki startowe, które polecam:

1. Wybierz dystrybucję ROS 2 zgodną z Twoim systemem.
2. Zainstaluj pakiety według oficjalnej dokumentacji.
3. Utwórz workspace i skompiluj przykładowy pakiet.
4. Uruchom prosty przykład węzła w C++ albo Pythonie.
5. Sprawdź tematy, usługi i akcje za pomocą narzędzi diagnostycznych.

Dobry pierwszy test wygląda prosto: jeden węzeł publikuje dane, drugi je subskrybuje. Potem dochodzi usługa, następnie akcja i dopiero dalej symulacja, transformacje tf2 oraz integracja z czujnikami. Taka kolejność ma sens, bo pozwala zrozumieć model komunikacji, zanim dojdzie fizyczny sprzęt i zacznie komplikować obraz sytuacji.

Do nauki bardzo przydają się Gazebo i tf2. Gazebo umożliwia testowanie algorytmów bez ryzyka dla robota, a tf2 porządkuje układy współrzędnych i transformacje przestrzenne. Bez tf2 nawet prosty robot potrafi nagle mieć kamerę patrzącą w ścianę mimo świetnego kodu sterującego. I niestety nie jest to rzadki widok.

Wskazówka: korzystaj z oficjalnej dokumentacji ROS 2 i przykładowych pakietów, bo tam znajdują się aktualne polecenia, struktura workspace oraz poprawne wersje narzędzi.

W projektach osadzonych ROS 2 potrafi działać również z mikrokontrolerami i środowiskami RTOS, między innymi przez DDS-XRCE. To otwiera drogę do edge computingu, czyli przetwarzania części zadań blisko czujnika lub aktuatora, bez wysyłania wszystkiego do mocniejszej jednostki centralnej.

Kto korzysta z ROS 2?

ROS 2 kieruje się do programistów robotyki, inżynierów automatyki, badaczy, integratorów systemów oraz firm budujących roboty i urządzenia autonomiczne. Najwięcej zyskują zespoły, które rozwijają systemy złożone, rozproszone i wielomodułowe.

Środowisko dobrze pasuje do:

• robotów mobilnych i AMR,
• manipulatorów przemysłowych,
• systemów wizyjnych,
• autonomicznych pojazdów,
• robotów usługowych,
• platform badawczych i dydaktycznych.

Sektor akademicki docenia szybkość prototypowania i gotowy model architektury. Przemysł wybiera ROS 2 z innych powodów: modularność, skalowalność, bezpieczeństwo, łatwiejszą integrację z różnymi komputerami oraz możliwość kontrolowania cyklu życia komponentów. W praktyce obie grupy spotykają się w tym samym miejscu, bo dzisiejszy prototyp bardzo często jutro staje się częścią produktu.

ROS 2 nie jest jednak środowiskiem dla osoby, która oczekuje gotowego robota po kilku kliknięciach. Wymaga zrozumienia węzłów, pakietów, komunikacji i podstaw programowania. Za to przy bardziej złożonych projektach szybko oddaje włożony wysiłek.

Wskazówka: podczas pracy zespołowej ustal jedną konwencję nazewnictwa węzłów, tematów, ramek tf i pakietów. Taki porządek oszczędza później wiele godzin debugowania.

Podsumowanie

ROS 2 to nowoczesne środowisko do tworzenia oprogramowania robotycznego, które porządkuje architekturę systemu, ułatwia komunikację między modułami i lepiej odpowiada na wymagania współczesnej robotyki niż ROS 1. Architektura peer-to-peer oparta na DDS, polityki QoS, lifecycle nodes, wsparcie dla C++ i Pythona oraz mechanizmy bezpieczeństwa sprawiają, że platforma dobrze sprawdza się zarówno w badaniach, jak i we wdrożeniach przemysłowych. Gdy projekt ma rosnąć, działać stabilnie i być podatny na rozwój, ROS 2 daje bardzo solidny fundament.

FAQ

Q: Czy ROS 2 działa bez Linuksa?

A: Tak. ROS 2 działa też na Windows i macOS, choć w praktyce wielu użytkowników nadal wybiera Linux jako środowisko bazowe.

Q: Czy ROS 2 nadaje się do małych projektów?

A: Tak, jeśli chcesz rozwijać projekt dalej. Do bardzo prostych zastosowań jego możliwości mogą być większe, niż potrzebujesz.

Q: Czy ROS 2 wymaga internetu podczas działania?

A: Nie. Po instalacji system działa lokalnie. Internet przydaje się głównie do pobierania pakietów, dokumentacji i aktualizacji.

Q: Czy ROS 2 ma wbudowane sterowanie silnikami?

A: Nie wprost. ROS 2 dostarcza framework komunikacji i organizacji kodu, a sterowanie silnikami realizujesz przez własne węzły lub integrację ze sterownikiem.

Q: Czy można mieszać C++ i Python w jednym projekcie ROS 2?

A: Tak. To częsty układ, bo część logiki piszesz w Pythonie, a części wymagające większej kontroli czasowej w C++.

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.