rmw_iceoryx2

1. Introduction
2. Feature Completeness
3. Performance
4. Setup
5. Examples
6. Benchmarks
7. FAQ
8. Commercial Support
9. Maintainers
10. 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 :).

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	✅
Server-Client	🚧
Message Serialization	✅
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

3. Clone the ROS 2 source:

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

4. Clone iceoryx2 source:

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

5. Clone rmw_iceoryx2:

   1. Either rolling or a specific version tag e.g. v0.1.0

   git clone -b rolling https://github.com/ekxide/rmw_iceoryx2.git ~/workspace/src/rmw_iceoryx2/

6. 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_talker_demo_nodes

7. 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
   

8. 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_talker_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_talker_demo_nodes talker_basic_types

Examples

Examples live in examples/ and are built and run via the root justfile. Requires just and tmux for convenient orchestration.

Run all commands from the workspace root:

# list the examples and their configurations
just -f src/rmw_iceoryx2/justfile list-examples

# build an example's packages
just -f src/rmw_iceoryx2/justfile build-example <example>

# run a configuration (opens a tmux session)
just -f src/rmw_iceoryx2/justfile run-example <example> <config>

For example, the basic talker/listener demo:

just -f src/rmw_iceoryx2/justfile build-example talker
just -f src/rmw_iceoryx2/justfile run-example talker basic_types

See examples/README.md for the full list and how to add an example.

Benchmarks

Targeted latency benchmarks live in benchmark/. Requires just for convenient orchestration.

They measure the one-way latency of rmw_iceoryx2 at a configurable publish rate for every pairing of ROS 2 and native iceoryx2 endpoints. The benchmark isolates overhead of the rclcpp layer across publish rates, not latency across payload sizes.

Run from the workspace root:

# build the benchmark packages
just -f src/rmw_iceoryx2/justfile build-benchmark

# list the available pairings and their parameters
just -f src/rmw_iceoryx2/justfile list-benchmarks

# run a pairing
just -f src/rmw_iceoryx2/justfile run-benchmark ros2-to-ros2 rate=1000 count=10000

See benchmark/README.md for the pairings, parameters, methodology, and how to interpret the results.

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.