rmw_iceoryx2

1. Introduction
2. Feature Completeness
3. Performance
4. Setup
5. FAQ
6. Commercial Support
7. Maintainers
8. Contributors

Introduction

Important

The implementation is still in an "alpha" stage. Not all functionality is implemented/stable so surprises are to be expected.

If encountering problems, please create an issue so we can converge to stability :).

Important

Currently only supports self-contained messages as message serialization is not yet implemented.

ROS 2 rmw implementation for iceoryx2.

iceoryx2 is a shared memory IPC middleware written in Rust for improved memory safety and easier safety certifiability. The implementation leverages the C++ bindings to the Rust core.

Feature Completeness

Feature	Status
Node	✅
Guard Condition	✅
Event	🚧
Publish-Subscribe (Copy)	✅
Publish-Subscribe (Loan)	✅
Publish-Subscribe (Serialized)	🚧
Server-Client	🚧
Waitset	✅
Graph	🚧
QoS	🚧
Logging	✅

Performance

Note

• The latency measurement can be reproduced with these instructions
• The measurements were taken on a Ryzen 3950X without a fine-tuned OS - lower latency could be expected on a fine-tuned target
• The performance_test tool uses rmw_iceoryx2 through the ROS 2 stack, which naturally introduces some overhead compared to pure iceoryx2
• The minimal possible latency achievable with iceoryx2 is in the nanosecond range

Setup

1. Set up your environment for building ROS 2 from source

2. Create a ROS 2 workspace:

   mkdir -p ~/workspace/src && cd ~/workspace

3. Clone the ROS 2 source:

   vcs import --input https://raw.githubusercontent.com/ros2/ros2/rolling/ros2.repos ~/workspace/src

4. Clone rmw_iceoryx2 and dependencies:

   vcs import --force --input https://raw.githubusercontent.com/ekxide/rmw_iceoryx2/refs/heads/main/rmw_iceoryx2.repos ~/workspace/src

5. Build ROS 2 with rmw_iceoryx2 and the demo nodes:

   cd ~/workspace/
   RMW_IMPLEMENTATION=rmw_iceoryx2_cxx colcon build --symlink-install --packages-up-to ros2cli_common_extensions rmw_iceoryx2_cxx rmw_iceoryx2_cxx_demo_nodes

6. Verify the build:

   source ~/workspace/install/setup.zsh # or setup.bash
   ros2 doctor --report

   The middleware should be properly set:

   RMW MIDDLEWARE
     middleware name    : rmw_iceoryx2_cxx
   

7. Verify functionality by running the demo nodes:

   1. Terminal 1

      source ~/workspace/install/setup.zsh # or setup.bash
      ROS_DISABLE_LOANED_MESSAGES=0 ros2 run rmw_iceoryx2_cxx_demo_nodes listener_basic_types

   2. Terminal 2

      source ~/workspace/install/setup.zsh # or setup.bash
      ROS_DISABLE_LOANED_MESSAGES=0 ros2 run rmw_iceoryx2_cxx_demo_nodes talker_basic_types

FAQ

Why another RMW implementation?

The goals of rmw_iceoryx2 are to:

1. Enable ROS 2 applications to leverage the high performance shared-memory communication offered by iceoryx2
2. Enable interoperability between ROS 2 and iceoryx2 applications

Is rmw_iceoryx2 targeting ASIL certification?

ASIL certification of rmw_iceoryx2 is currently not a priority. Reason being that even if it were to be certified, a certified flavour of ROS 2 would additionally be required to produce a fully certified application, which is a large undertaking and not in scope for us.

The iceoryx2 implementation, however, is prepared for and targeting ASIL-D certification. With interoperability between iceoryx2 and rmw_iceoryx2, safety-critical components built on iceoryx2 (which may be certified up to ASIL-D) can communicate with ROS 2 components which may not be certified, or certified at a lower rating (e.g. Quality Management (QM)), thus taking advantage of the vast development ecosystem offered by ROS 2.

If you have a need for some level of certification for rmw_iceoryx2, feel free to get in touch. We would be happy to discuss your use-case and explore the options together.

Is rmw_iceoryx2 capable of host-to-host communication?

In its current form, rmw_iceoryx2 only supports communication within a single host. However, iceoryx2 has so-called Gateways and Tunnels on the roadmap which will support this use-case and should be available in the coming months.

A Gateway bridges between hosts using a host-to-host-capable middleware with a defined on-wire protocol, such as zenoh, which runs in an isolated process and exchanges payloads via iceoryx2 shared-memory communication. This keeps network communication isolated from safety-critical software.

A Tunnel provides a more direct approach to host-to-host communication while maintaining the same process isolation model. However, instead of using an intermediary middleware like zenoh, a Tunnel writes message payloads directly to the transport layer. For example, a Tunnel using smoltcp would handle TCP/IP communication directly, offering lower latency but requiring more careful handling of network communication details.

What is a self-contained message?

A message definition that does not contain any pointers or references to addresses in a process's virtual address space i.e. satisfy TriviallyCopyable named requirement.

Self-contained messages can be stored in shared memory without any serialization and subsequently read by any other process on the host system. Binaries should be compiled with the same compiler flags to ensure consistent memory representation.

How can I verify that iceoryx2 is being used by my ROS 2 application?

The iox2 CLI can be used to verify services are created for ROS 2 endpoints:

$ iox2 service list
[
    PublishSubscribe("ros2://topics/basic_types"),
    Event("ros2://topics/basic_types"),
    PublishSubscribe("ros2://topics/parameter_events"),
    Event("ros2://topics/parameter_events"),
]

Commercial Support

info@ekxide.io

accelerated development safety certification priority bug-fixing training and consulting

Maintainers

»orecham«

Contributors

It could be you!

This project is and will always remain fully open source. Looking to use iceoryx2 in your ROS 2 application but finding the implementation lacking in some way? Your contributions can help improve it more quickly, and we'll provide full support and guidance along the way.