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.
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.
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.
Konkretny pakiet mapujący C API rmw na API danego middleware, np. rmw_fastrtps_cpp, rmw_cyclonedds_cpp, rmw_connextdds, rmw_zenoh_cpp.
Oficjalna
Mechanizm serializacji/deserializacji wiadomości generowany przez rosidl; statyczny (kod na etapie budowania) lub dynamiczny/introspekcyjny (w czasie działania).
Oficjalna
Podzbiór polityk Quality of Service bazowego middleware udostępniany przez ROS 2 (np. reliability, durability, history, depth).
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.
Publisher i subscriber z niekompatybilnymi profilami QoS (np. reliability) nie nawiążą połączenia mimo poprawnej nazwy tematu.
ROS 2 udostępnia tylko część konfiguracji bazowego middleware; zaawansowane strojenie (np. tryb publikacji, zero-copy) wymaga natywnej konfiguracji dostawcy (pliki XML, zmienne środowiskowe).
Zdefiniowano interfejs middleware jako warstwę abstrakcji nad DDS, oddzielającą bibliotekę kliencką ROS 2 od dostawcy.
ROS 2 ustabilizował wsparcie dla wymiennych backendów DDS (Fast DDS, Cyclone DDS, RTI Connext) wybieranych przez RMW_IMPLEMENTATION.
Pojawił się rmw_zenoh_cpp — implementacja RMW oparta na Zenoh, demonstrująca backend inny niż DDS w nowszych dystrybucjach ROS 2.
Zmienna środowiskowa wskazująca pakiet implementacji RMW (np. rmw_fastrtps_cpp, rmw_cyclonedds_cpp, rmw_connextdds, rmw_zenoh_cpp). Domyślnie rmw_fastrtps_cpp.
Konfiguracja gwarancji komunikacji (reliability, durability, history, depth i inne) w granicach podzbioru udostępnianego przez ROS 2.
Wybór między statycznym type support (kod generowany na etapie budowania) a dynamicznym/introspekcyjnym (w czasie działania).
RMW to programowa warstwa abstrakcji nad middleware sieciowym — nie zależy od konkretnego akceleratora i działa na standardowym CPU.
