Draft rosidl.0c REP by hidmic · Pull Request #22 · openrobotics/reps

hidmic · 2026-01-21T21:36:52Z

Connected to https://discourse.openrobotics.org/t/is-it-time-to-discuss-rosidl/49867. Pending ROS PMC sponsor assignment, if the PMC is willing.

Reference implementation pending design discussion (and resolution of some TBDs).

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>

hidmic · 2026-01-27T11:05:46Z

@mjcarroll before building anything, it'd be good to reach some consensus. This needs a PMC sponsor too IIUC (if the group agrees this is worthwhile, of course).

mjcarroll · 2026-01-27T16:26:12Z

I would like to put this under the responsibility of the newly formed accelerated memory transport working group, since we have been having discussions about the rcl::Buffer approach there as well. Can we plan on adding this to the first agenda there?

We can rectify what is here against the proposed rcl::Buffer approach.

hidmic · 2026-01-27T17:15:32Z

Sure thing. ~~Who should we loop into this?~~ Edit: pulling @ahcorde in.

MiguelCompany

A very sound proposal.
Leaving two minor comments

MiguelCompany · 2026-02-03T13:46:00Z

_posts/rep-0157.md

+
+- It is binary compatible. XCDRv1 serializes full sized data sequentially, and while big endian by default, it can be configured to operate in little endian like the vast majority of modern compute platforms.
+- It is sufficiently descriptive. XCDRv1 serializes enough information (i.e. alignments, sizes) to recover the message if its structure is known.
+- It ensures over-the-wire compatibility. At the time of writing of this REP, most RMW implementations, including all Tier 1 RMW implementations, use XCDRv1 as serialization format. Messages exchanged by processes using the proposed re-design and the original design will be mutually intelligible. TBD: should we be using XCDRv2? Append-only message extension would be easier to support.


Regarding XCDRv2, it would have the following caveats:

The maximum field alignment is 4 bytes, which might make access to 64-bit data types slower in some architectures.

There is a possibility os breaking backwards wire-compatibility

Yeah, I saw the change in alignment. I get OMG was trying to reduce padding but I'm not that sure it was a smart move.

MiguelCompany · 2026-02-03T13:53:29Z

_posts/rep-0157.md

+
+For the reference implementation, [XCDRv1](https://www.omg.org/spec/DDS-XTypes/1.3/PDF) is chosen as the serialization format (and thus as the in-memory representation for message views) for a number of reasons:
+
+- It is binary compatible. XCDRv1 serializes full sized data sequentially, and while big endian by default, it can be configured to operate in little endian like the vast majority of modern compute platforms.


Care should be taken when receiving a payload in an endianness that differs from the one in which the application is running

Yes, this should be trivial. Endianness is specified in the payload. That said, I think we can switch to little endian everywhere with no consequences other than performance degradation for cross-distribution communication (which is not guaranteed to work anyways IIRC) if we have to deserialize. I honestly tried to find a rationale for big endian protocols and I couldn't find any other than that's how it has always been for network protocols.

I honestly tried to find a rationale for big endian protocols and I couldn't find any other than that's how it has always been for network protocols.

My understanding is that "it's always been done that way", but it seems like the tides are shifting towards little endian for the same reason that we are considering it here: protobuf, flatbuffers, capnproto, parquet, arrow, can't all be wrong, right?

My understanding is that "it's always been done that way", but it seems like the tides are shifting towards little endian for the same reason that we are considering it here: protobuf, flatbuffers, capnproto, parquet, arrow, can't all be wrong, right?

The TCP/IP protocol uses big-endian as "network byte order". My guess is that it was standardized by people using IBM machines back in the day, and ended up being the default endianness for other applications built on top of TCP/IP as well.

gbiggs · 2026-02-11T00:25:18Z

_posts/rep-0157.md

@@ -0,0 +1,349 @@
+---
+layout: post
+REP: 0157:2026


Please rename the file to match: rep-0157:2026.md.

gbiggs · 2026-02-11T00:27:28Z

_posts/rep-0157.md

+
+`rosidl` is one the oldest subsystems of ROS 2. [Initial research](https://design.ros2.org/articles/serialization.html) dates back to 2013. C and C++ message generators were first released with Alpha 1, each with their own runtime representations. Language-specific, member-based interfaces were simple enough to implement and verifiably performant. The first few DDS based middlewares had their own vendor-specific IDL to comply with, for interoperability and full feature support, and their own wire formats, thus some data processing (ie. copy, conversion, serialization) cost had to be paid one way or another and it was deemed affordable. 
+
+`rosidl` design hasn't changed substantially since then. Unfortunately, even if well suited for ROS 2 systems distributed over many hosts in a network, its simplicity sacrifices performance for the fairly common single host topology. 


Suggested change

`rosidl` design hasn't changed substantially since then. Unfortunately, even if well suited for ROS 2 systems distributed over many hosts in a network, its simplicity sacrifices performance for the fairly common single host topology.

`rosidl` design hasn't changed substantially since then. Unfortunately, even if well suited for ROS systems distributed over many hosts in a network, its simplicity sacrifices performance for the fairly common single host topology.

Please change all instances of "ROS 2" to "ROS".

gbiggs · 2026-02-11T00:28:03Z

_posts/rep-0157.md

+
+# Motivation
+
+`rosidl` is one the oldest subsystems of ROS 2. [Initial research](https://design.ros2.org/articles/serialization.html) dates back to 2013. C and C++ message generators were first released with Alpha 1, each with their own runtime representations. Language-specific, member-based interfaces were simple enough to implement and verifiably performant. The first few DDS based middlewares had their own vendor-specific IDL to comply with, for interoperability and full feature support, and their own wire formats, thus some data processing (ie. copy, conversion, serialization) cost had to be paid one way or another and it was deemed affordable. 


Please leave this single instance of "ROS 2" as-is, as it is denoting historical information.

gbiggs · 2026-02-11T00:29:10Z

_posts/rep-0157.md

+
+# Motivation
+
+`rosidl` is one the oldest subsystems of ROS 2. [Initial research](https://design.ros2.org/articles/serialization.html) dates back to 2013. C and C++ message generators were first released with Alpha 1, each with their own runtime representations. Language-specific, member-based interfaces were simple enough to implement and verifiably performant. The first few DDS based middlewares had their own vendor-specific IDL to comply with, for interoperability and full feature support, and their own wire formats, thus some data processing (ie. copy, conversion, serialization) cost had to be paid one way or another and it was deemed affordable. 


Please reformat the document according to REP-0001:2025's "one sentence per line" rule.

gbiggs · 2026-02-11T00:31:23Z

_posts/rep-0157.md

+REP: 0157:2026
+title: Minimal Overhead Messaging Support
+author: Michel Hidalgo
+PMC Sponsor: TBD


You need to find a sponsor before this proposal can become a Draft REP.

@gbiggs @hidmic I'd be glad to sponsor this

gbiggs · 2026-02-11T00:45:05Z

_posts/rep-0157.md

+
+# Abstract
+
+This REP proposes a re-design of the `rosidl` messaging system to broaden the scope of application of zero-copy transports, including those that deal with seggregated memory models.


Please add a little more information about what the REP is specifying.

gbiggs · 2026-02-11T02:45:25Z

_posts/rep-0157.md

+---
+layout: post
+REP: 0157:2026
+title: Minimal Overhead Messaging Support


Please make the title more specific, e.g. "Minimal Overhead Messaging Support Using..."

Draft rosidl.0c REP

740b353

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>

hidmic requested review from gbiggs and tfoote as code owners January 21, 2026 21:36

hidmic added 2 commits January 22, 2026 18:56

Minor corrections

e132552

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>

Document draft typesupport APIs

09185dd

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>

MiguelCompany reviewed Feb 3, 2026

View reviewed changes

gbiggs requested changes Feb 11, 2026

View reviewed changes


		For the reference implementation, [XCDRv1](https://www.omg.org/spec/DDS-XTypes/1.3/PDF) is chosen as the serialization format (and thus as the in-memory representation for message views) for a number of reasons:

		- It is binary compatible. XCDRv1 serializes full sized data sequentially, and while big endian by default, it can be configured to operate in little endian like the vast majority of modern compute platforms.


		`rosidl` is one the oldest subsystems of ROS 2. [Initial research](https://design.ros2.org/articles/serialization.html) dates back to 2013. C and C++ message generators were first released with Alpha 1, each with their own runtime representations. Language-specific, member-based interfaces were simple enough to implement and verifiably performant. The first few DDS based middlewares had their own vendor-specific IDL to comply with, for interoperability and full feature support, and their own wire formats, thus some data processing (ie. copy, conversion, serialization) cost had to be paid one way or another and it was deemed affordable.

		`rosidl` design hasn't changed substantially since then. Unfortunately, even if well suited for ROS 2 systems distributed over many hosts in a network, its simplicity sacrifices performance for the fairly common single host topology.


		# Motivation

		`rosidl` is one the oldest subsystems of ROS 2. [Initial research](https://design.ros2.org/articles/serialization.html) dates back to 2013. C and C++ message generators were first released with Alpha 1, each with their own runtime representations. Language-specific, member-based interfaces were simple enough to implement and verifiably performant. The first few DDS based middlewares had their own vendor-specific IDL to comply with, for interoperability and full feature support, and their own wire formats, thus some data processing (ie. copy, conversion, serialization) cost had to be paid one way or another and it was deemed affordable.


		# Abstract

		This REP proposes a re-design of the `rosidl` messaging system to broaden the scope of application of zero-copy transports, including those that deal with seggregated memory models.

Conversation

hidmic commented Jan 21, 2026

Uh oh!

hidmic commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mjcarroll commented Jan 27, 2026

Uh oh!

hidmic commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MiguelCompany left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hidmic Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

hidmic commented Jan 27, 2026 •

edited

Loading

hidmic commented Jan 27, 2026 •

edited

Loading

hidmic Feb 3, 2026 •

edited

Loading