Gateway to ROS 2¶

Learning Objectives

This series of articles shows how to compose a system from both ROS 2 and iceoryx2 applications, and how to choose between the approaches for connecting them.

Consider the following: you and your team have been working on a robotics project. An idea so novel, unique and brilliant, that it will disrupt the industry and change the way we all live. Forever! You have spent the last few years building a prototype in ROS 2, and it is finally complete. Functionally, it works.

But it is not yet perfect. Responsiveness could be snappier. Communication latency has become a bottleneck, CPU load is high, especially when communicating larger payloads. Or safety certification has reared its head as a barrier to production.

With iceoryx2 it is possible to address these issues. The ROS 2 gateway makes it possible to compose a hybrid system, consisting of both ROS 2 and iceoryx2 applications.

        %%{init: {"flowchart": {"subGraphTitleMargin": {"top": 10, "bottom": 8}}} }%%
flowchart LR
    subgraph ros2["ROS 2"]
        n1["Node"]:::external
        n2["Node"]:::external
    end

    gw["Gateway"]:::gateway

    subgraph iox2["iceoryx2"]
        a1["Application"]
        a2["Application"]
    end

    n1 <-- "DDS" --> n2
    n2 <-- "DDS" --> gw
    gw <-- "SHM" --> a1
    a1 <-- "SHM" --> a2

Gateway connecting ROS 2 and iceoryx2 domains¶

Maybe moving a few key components to iceoryx2 is enough. Everything else can stay in ROS 2 and keep the tools and packages of its ecosystem. Or maybe the entire system will eventually move to iceoryx2. The gateway then allows the system to move over component by component.

In This Series

First we will go over the basic usage of the ROS 2 gateway, then take a look at some different approaches for exchanging payloads across the boundary. The approach that fits your system best is a case-by-case design decision. Finally, we will look at how to make execution event-driven: