Robotyka

RMW

2014AktywnyOpublikowano: 23 września 2026Aktualizacja: 23 września 2026Opublikowany

Warstwa abstrakcji w ROS 2 oddzielająca bibliotekę kliencką (rcl) od konkretnej implementacji middleware (zwykle DDS) i definiująca jednolite C API komunikacji.

Kluczowa innowacja

Wprowadzenie warstwy abstrakcji, która oddziela rdzeń ROS 2 (rcl/rclcpp/rclpy) od konkretnej implementacji middleware komunikacyjnego (zwykle DDS), umożliwiając podmianę backendu bez zmiany kodu aplikacji.

Kategoria

Robotyka

Poziom abstrakcji

Building block

Poziom operacji

Sterowanie robotemWdrożenie

Zastosowania

Podmiana backendu middleware w ROS 2 bez zmiany koduKomunikacja pub/sub, usługi i akcje między węzłami ROS 2Dobór dostawcy DDS pod wydajność, licencję lub wsparcie real-timeSystemy wbudowane i real-time (RTI Connext, Cyclone DDS)Konfiguracja polityk QoS komunikacjiTransport dużych danych i zero-copy przez współdzielenie pamięciKomunikacja poza-DDS przez rmw_zenoh (Zenoh)

Jak działa

1) Kod aplikacji korzysta z rclcpp/rclpy, które wywołują wspólny rdzeń rcl. 2) rcl wywołuje C API zdefiniowane przez rmw (m.in. tworzenie węzłów, publisherów i subscriberów, publikacja/odbiór wiadomości, usługi, akcje, konfiguracja QoS, discovery). 3) Wybrana implementacja rmw (np. rmw_fastrtps_cpp) mapuje te wywołania na API konkretnego middleware DDS. 4) Wiadomości są serializowane przez mechanizm type support generowany przez rosidl — w wariancie statycznym (kod generowany na etapie budowania, np. rmw_fastrtps_cpp) lub dynamicznym/introspekcyjnym (mapowanie w czasie działania, np. rmw_fastrtps_dynamic_cpp). 5) Implementację wskazuje zmienna środowiskowa RMW_IMPLEMENTATION (domyślnie rmw_fastrtps_cpp); ROS 2 udostępnia tylko podzbiór polityk QoS bazowego middleware.

Rozwiązany problem

ROS 1 opierał komunikację na własnych protokołach (TCPROS/UDPROS) i scentralizowanym masterze. ROS 2 potrzebował sposobu na wykorzystanie dojrzałych, standaryzowanych implementacji middleware (DDS) bez przywiązywania rdzenia i kodu aplikacji do jednego dostawcy. RMW rozwiązuje to, ukrywając API konkretnego middleware za jednolitym interfejsem, dzięki czemu można wymieniać backend (np. dla wydajności, licencji, wsparcia real-time czy zgodności sieciowej) bez modyfikacji kodu użytkownika ani rekompilacji osobnych pakietów binarnych per middleware.

Komponenty

rmw C APIKontrakt interfejsu, który implementują wszystkie backendy RMW.

Zestaw funkcji C definiujących kontrakt middleware: tworzenie węzłów, publisherów i subscriberów, publikacja/odbiór wiadomości, usługi, akcje, konfiguracja QoS i discovery.

Implementacja RMW (adapter backendu)Tłumaczy wywołania rmw na operacje wybranego middleware.

Konkretny pakiet mapujący C API rmw na API danego middleware, np. rmw_fastrtps_cpp, rmw_cyclonedds_cpp, rmw_connextdds, rmw_zenoh_cpp.

rmw_fastrtps_cppDomyślna implementacja oparta na eProsima Fast DDS ze statycznym type support.

rmw_fastrtps_dynamic_cppWariant Fast DDS używający introspekcyjnego type support w czasie działania.

rmw_cyclonedds_cppImplementacja oparta na Eclipse Cyclone DDS.

rmw_connextddsImplementacja oparta na RTI Connext DDS Professional (rmw_connextddsmicro jest przestarzała).

rmw_zenoh_cppImplementacja RMW oparta na Zenoh (poza-DDS), używająca bindingów zenoh-cpp.

Oficjalna

Type support (rosidl)Odwzorowuje typy wiadomości ROS na reprezentację middleware.

Mechanizm serializacji/deserializacji wiadomości generowany przez rosidl; statyczny (kod na etapie budowania) lub dynamiczny/introspekcyjny (w czasie działania).

Oficjalna

Polityki QoSSteruje gwarancjami dostarczania i buforowaniem komunikacji.

Podzbiór polityk Quality of Service bazowego middleware udostępniany przez ROS 2 (np. reliability, durability, history, depth).

Implementacja

Implementacje referencyjne

ros2/rmw

C · Open Robotics / ROS 2

Oficjalna

rmw_fastrtps

C++ · eProsima / ROS 2

Oficjalna

rmw_cyclonedds

C++ · Eclipse Cyclone DDS / ROS 2

Pułapki implementacyjne

Niezgodne implementacje RMW między węzłamiWysoka

Węzły komunikują się tylko wtedy, gdy ich backendy są interoperacyjne. Implementacje DDS współdzielą protokół RTPS, ale rmw_zenoh (Zenoh) nie jest interoperacyjne z backendami DDS.

Rozwiązanie:Ujednolić RMW_IMPLEMENTATION w całym systemie; weryfikować backend przez `ros2 doctor --report`.

Niezgodność polityk QoSWysoka

Publisher i subscriber z niekompatybilnymi profilami QoS (np. reliability) nie nawiążą połączenia mimo poprawnej nazwy tematu.

Rozwiązanie:Dobierać zgodne profile QoS po obu stronach; korzystać z predefiniowanych profili ROS 2.

Ograniczony podzbiór funkcji middlewareŚrednia

ROS 2 udostępnia tylko część konfiguracji bazowego middleware; zaawansowane strojenie (np. tryb publikacji, zero-copy) wymaga natywnej konfiguracji dostawcy (pliki XML, zmienne środowiskowe).

Rozwiązanie:Do zaawansowanego strojenia użyć natywnych mechanizmów dostawcy (np. FASTRTPS/CYCLONEDDS_URI).

Ewolucja

Oryginalny paper · 2014 · ROS 2 Design

ROS Middleware Interface

2014

Artykuł projektowy RMW

Punkt przełomowy

Zdefiniowano interfejs middleware jako warstwę abstrakcji nad DDS, oddzielającą bibliotekę kliencką ROS 2 od dostawcy.

2017

Wielu dostawców DDS w ROS 2

ROS 2 ustabilizował wsparcie dla wymiennych backendów DDS (Fast DDS, Cyclone DDS, RTI Connext) wybieranych przez RMW_IMPLEMENTATION.

2024

rmw_zenoh jako alternatywa poza-DDS

Pojawił się rmw_zenoh_cpp — implementacja RMW oparta na Zenoh, demonstrująca backend inny niż DDS w nowszych dystrybucjach ROS 2.

Hiperparametry (konfigurowalne osie)

Wybór implementacji RMWKrytyczna

Zmienna środowiskowa wskazująca pakiet implementacji RMW (np. rmw_fastrtps_cpp, rmw_cyclonedds_cpp, rmw_connextdds, rmw_zenoh_cpp). Domyślnie rmw_fastrtps_cpp.

rmw_fastrtps_cppDomyślny backend (eProsima Fast DDS).

rmw_cyclonedds_cppEclipse Cyclone DDS.

rmw_zenoh_cppBackend oparty na Zenoh.

Polityki QoSWysoka

Konfiguracja gwarancji komunikacji (reliability, durability, history, depth i inne) w granicach podzbioru udostępnianego przez ROS 2.

Tryb type supportŚrednia

Wybór między statycznym type support (kod generowany na etapie budowania) a dynamicznym/introspekcyjnym (w czasie działania).

staticnp. rmw_fastrtps_cpp — wyższa wydajność.

dynamic/introspectionnp. rmw_fastrtps_dynamic_cpp — mapowanie w czasie działania.