ROS 2 w produkcji: co się zmienia przy przejściu z laboratorium do floty robotów

Co się zmienia, gdy ROS 2 przechodzi z laboratorium na halę produkcyjną?

Krótka odpowiedź: prawie wszystko poza samym API. Węzły, tematy i usługi wyglądają identycznie na jednym robocie testowym i w hali ze stoma jednostkami, ale założenia, na których opiera się cała komunikacja — stabilna sieć, jeden segment Wi-Fi, brak obcego ruchu, ręczny restart w razie awarii — przestają się sprawdzać. W laboratorium DDS (Data Distribution Service, domyślna warstwa komunikacyjna ROS 2) automatycznie wykrywa wszystkie węzły, bez żadnego dodatkowego wysiłku ze strony zespołu. We flocie ten sam mechanizm wykrywania potrafi zalać sieć pakietami multicast, wymieszać ruch sieciowy dwóch niezależnych robotów stojących obok siebie na hali albo uniemożliwić bezpieczne zdalne aktualizowanie oprogramowania. Przejście z laboratorium do produkcji to więc nie kwestia „czy kod działa“, tylko czy architektura komunikacyjna, wybór wersji ROS 2 i sposób zarządzania flotą poradzą sobie ze skalą, pracą non-stop 24/7 i wymogiem przewidywalności.

Dlaczego jeden robot w laboratorium nie jest dobrym testem dla floty?

Na stole testowym błąd komunikacyjny kończy się ponownym uruchomieniem procesu. W hali magazynowej ten sam błąd — zagubiony pakiet DDS, kolizja identyfikatorów domeny, przeciążony switch — może zatrzymać linię albo doprowadzić do kolizji dwóch jednostek. Robotyka produkcyjna wymaga więc, żeby warstwa komunikacyjna była projektowana od razu pod kątem dziesiątek albo setek uczestników sieci, a nie doklejana post factum, gdy flota już rośnie.

Czym jest DDS i dlaczego staje się wąskim gardłem przy skalowaniu?

DDS to standard komunikacji publikuj–subskrybuj, na którym domyślnie opiera się ROS 2 — to on odpowiada za wykrywanie węzłów, przesyłanie tematów i usług między robotami oraz stacjami operatorskimi. W małej instalacji ta automatyczność jest zaletą: nie trzeba ręcznie konfigurować, kto z kim rozmawia. Problem pojawia się przy skalowaniu, ponieważ mechanizm wykrywania w wielu implementacjach DDS opiera się na rozgłaszaniu (multicast), które rośnie nieliniowo wraz z liczbą uczestników. Kilkanaście robotów w jednej podsieci potrafi wygenerować ruch wykrywania porównywalny z całym normalnym ruchem roboczym, a błędnie skonfigurowane identyfikatory domeny DDS prowadzą do tego, że dwie niezależne floty „widzą“ nawzajem swoje tematy. To dlatego zespoły wdrażające ROS 2 produkcyjnie zwykle segmentują sieć, ograniczają zasięg wykrywania i traktują konfigurację DDS jako osobny element architektury, a nie ustawienie domyślne, które można zignorować.

Czy DDS pozostaje jedyną opcją w ROS 2?

Nie — i to jedna z ważniejszych zmian ostatnich dwóch lat. Wraz z wydaniem Jazzy Jalisco społeczność ROS 2 wprowadziła rmw_zenoh, alternatywną warstwę komunikacyjną opartą na protokole Zenoh, a pełne wsparcie dla niej pojawiło się przy wydaniu Kilted Kaiju w maju 2025 roku. Zenoh został zaprojektowany z myślą o rozproszonych, wielkoskalowych wdrożeniach (w tym zastosowaniach motoryzacyjnych), gdzie klasyczne wykrywanie oparte na multicaście słabo się skaluje. Mimo to DDS pozostaje domyślną warstwą komunikacyjną ROS 2 — Zenoh to opcja do rozważenia przy projektowaniu floty, a nie zamiennik, który trzeba wdrożyć od razu.

Która wersja ROS 2 nadaje się do wdrożenia produkcyjnego?

To pytanie, które w praktyce sprowadza się do jednego wyboru: LTS (Long Term Support) czy wydanie standardowe. Dla floty, która ma pracować latami bez ciągłych migracji, LTS jest naturalnym wyborem — dłuższe okno wsparcia oznacza mniej wymuszonych aktualizacji w środowisku, gdzie każda zmiana wymaga testów regresyjnych na sprzęcie.

Wydanie	Data wydania	Typ	Wsparcie do
Jazzy Jalisco	23 maja 2024	LTS	koniec maja 2029
Kilted Kaiju	23 maja 2025	standardowe	listopad 2026
Lyrical Luth	maj 2026	LTS	maj 2031

Jazzy Jalisco — wydanie 11. w tej samej ciągłej numeracji co Kilted Kaiju, ponieważ to kolejne wydania w tej samej serii — było pierwszym wydaniem z oficjalnym wsparciem Tier 1 dla Ubuntu 24.04 Noble Numbat na architekturach arm64 i amd64 oraz dla Windows 10, co dla wielu integratorów oznaczało pierwszą okazję do migracji na nowszy system operacyjny bez utraty statusu w pełni wspieranej platformy. Kilted Kaiju, jedenaste wydanie ROS 2, wypuszczone 23 maja 2025 roku, jest wydaniem standardowym z krótszym oknem wsparcia — do listopada 2026 roku — co sprawia, że lepiej nadaje się do testowania nowości (jak wspomniany rmw_zenoh) niż do wieloletniego wdrożenia floty. Najnowsze wydanie, Lyrical Luth z maja 2026 roku, dwunaste w kolejności, wraca do statusu LTS ze wsparciem do maja 2031 roku — to obecnie najdłuższy dostępny horyzont planowania dla nowego wdrożenia produkcyjnego.

Co to oznacza w praktyce dla zespołu planującego flotę?

Zespół, który dziś projektuje architekturę floty od zera, ma sensowny wybór między Jazzy Jalisco (sprawdzone, ugruntowane, wsparcie do 2029) a Lyrical Luth (najświeższe LTS, wsparcie do 2031, ale krócej sprawdzone w praktycznych wdrożeniach). Wydania standardowe, takie jak Kilted Kaiju, warto traktować jako poligon do testowania nowych mechanizmów middleware przed ich przeniesieniem na warstwę produkcyjną opartą na LTS — nie jako docelową podstawę dla floty, która ma pracować bez przerwy przez kilka lat.

Jak wygląda ROS 2 w praktyce na przykładzie floty produkcyjnej?

Dobrym przykładem skalowania od pojedynczego prototypu do floty działającej w realnych magazynach jest brytyjska firma Dexory, która zbudowała swoją autonomiczną flotę robotów skanujących magazyny na ROS 2 i stosie nawigacyjnym Nav2. Nad rozwojem skalowalnej autonomii w firmie czuwa Dr Marcus Schuenemann, pełniący funkcję Head of Autonomy — a sama firma w październiku 2025 roku pozyskała finansowanie w wysokości 165 milionów dolarów, w tym 100 milionów dolarów w formie kapitału, z rundą prowadzoną przez zespół Growth funduszu Eurazeo, przy udziale LTS Growth, Endeavor Catalyst oraz dotychczasowych inwestorów (Atomico, Lakestar, Elaia, Latitude Ventures), a dodatkowo 65 milionów dolarów w formie finansowania dłużnego od Bootstrap Europe; dyrektorem generalnym Dexory jest Andrei Danescu.

Warto uczciwie zaznaczyć, że źródła rozjeżdżają się co do dokładnej skali floty Dexory w danym momencie — jedno mówi o ponad 200 jednostkach pracujących na świecie, inne cytuje wcześniejszą wypowiedź o skalowaniu „od zera do 90 robotów“ na etapie rundy Series B. Różnica prawdopodobnie wynika z tego, że obie liczby dotyczą różnych punktów w czasie, ale nie udało się potwierdzić aktualnej wartości drugim niezależnym źródłem, więc traktujemy to jako otwarte pytanie, a nie twardy fakt. Sam wybór ROS 2 i Nav2 jako podstawy floty pozostaje jednak dobrze udokumentowany i pokazuje, że standardowy stos open source radzi sobie z wieloma jednostkami pracującymi równolegle w realnym środowisku magazynowym, a nie tylko w laboratorium.

Jakie są największe pułapki przy skalowaniu ROS 2 z jednego robota na flotę?

Poniżej najczęstsze różnice między konfiguracją laboratoryjną a produkcyjną, które zespoły odkrywają zwykle dopiero przy pierwszym wdrożeniu na skalę.

Obszar	Laboratorium (1 robot)	Flota produkcyjna (dziesiątki jednostek)
Wykrywanie węzłów DDS	Automatyczne, bez konfiguracji	Wymaga segmentacji sieci i kontroli zasięgu wykrywania
Sieć	Jeden segment Wi-Fi, mały ruch	Wiele stref, przeciążenie multicastem, potrzeba QoS
Aktualizacje oprogramowania	Ręczna instalacja na jednej maszynie	Zarządzane wdrożenia z wersjonowaniem i wycofywaniem zmian
Wybór wydania ROS 2	Dowolne, testowe	LTS preferowane ze względu na przewidywalność wsparcia
Monitorowanie	Logi lokalne, obserwacja na żywo	Telemetria floty, alarmy, dashboardy centralne
Bezpieczeństwo komunikacji	Zwykle pominięte	Kontrola dostępu do tematów i szyfrowanie ruchu

Największym błędem popełnianym przy przejściu z laboratorium do floty jest traktowanie DDS jako „ustawienia, które po prostu działa“, zamiast elementu architektury wymagającego świadomej konfiguracji domen, filtrów wykrywania i segmentacji sieci. Drugim częstym błędem jest wybór wydania ROS 2 pod kątem najnowszych funkcji zamiast pod kątem długości wsparcia — standardowe wydanie z krótkim oknem, takie jak Kilted Kaiju, potrafi wymusić kosztowną migrację floty w środku cyklu życia produktu, jeśli zostanie potraktowane jako baza produkcyjna zamiast poligonu testowego.

Decyzje podjęte na etapie wyboru middleware i wersji dystrybucji rzutują też na to, jak wygląda dalsze zarządzanie flotą po wdrożeniu — od procesu aktualizacji, przez monitorowanie kondycji poszczególnych jednostek, po reagowanie na awarie w czasie rzeczywistym, co szerzej opisuje RobotOps — praktyka utrzymania i skalowania floty robotów w ruchu. Sam wybór warstwy komunikacyjnej to jednak dopiero jeden element szerszego stosu technologicznego, na którym opiera się każdy fizyczny system autonomiczny — pełny obraz tego, jak te warstwy się ze sobą łączą, opisuje artykuł o pełnym stosie fizycznej AI.

Jak testować architekturę floty przed wdrożeniem na hali?

Zanim nowa konfiguracja DDS albo nowe wydanie ROS 2 trafi na prawdziwe roboty, warto przetestować ją w środowisku, które odwzorowuje skalę docelowej floty bez ryzyka kolizji fizycznych — do tego służy symulacja wielu robotów działających równolegle w cyfrowym bliźniaku, gdzie można obciążyć sieć ruchem odpowiadającym docelowej liczbie jednostek, zanim jakikolwiek robot wyjedzie na halę. Dane zbierane z takiej floty — zarówno telemetria działania, jak i nagrania z sesji teleoperacji wykorzystywane do trenowania modeli — to osobny temat, który szerzej omawia artykuł o teleoperacji i zbieraniu danych z robotów.

Podsumowanie: co zabrać z laboratorium, a co zaprojektować od nowa

Kod aplikacyjny napisany pod ROS 2 zwykle przenosi się z laboratorium do floty bez większych zmian — węzły, tematy i usługi działają tak samo niezależnie od skali. Tym, co trzeba zaprojektować od nowa, jest warstwa komunikacyjna: konfiguracja DDS pod kątem segmentacji i ograniczenia wykrywania, świadomy wybór między DDS a alternatywami takimi jak Zenoh, oraz wybór wydania ROS 2 — LTS zamiast wydania standardowego — dopasowanego do horyzontu czasowego, w jakim flota ma pracować bez kosztownej migracji. Więcej pojęć z tego obszaru — od DDS po middleware i warstwy autonomii — znajdziesz w słowniku pojęć fizycznej AI, a szerszy kontekst całego stosu technologicznego, w którym ROS 2 jest tylko jedną z warstw, opisuje hub „Stack fizycznej AI“. O tym, jak ta sama warstwa DDS/ROS 2 pełni rolę harnessu bezpieczeństwa w agentowym ujęciu robota, piszemy w artykule agentic engineering dla fizycznej AI.