Correctly map byte[] AKA IDL type sequence<octet> to Python type bytes

[aprotyas]

As reported in #134, the message type byte[] AKA IDL type sequence<octet> is mapped to a sequence of bytes, rather than a single bytes instance - which is the mapped type documented in the design doc.

The goal of this (draft, for now) PR is to rectify that behavior.

In 14969f2, I've modified the interface tests for Arrays, BoundedSequences, and UnboundedSequences to reflect the correct mapping from IDL type sequence<octet> to Python type bytes, rather than Python type list. As expected, these changes will cause test failures in the build job.

Signed-off-by: Abrar Rahman Protyasha aprotyas@u.rochester.edu

[russkel]

Hi @aprotyas did this get anywhere?

[aprotyas]

@russkel no, I didn't look into this much further than what's in the PR. Feel free to work on it if you want!

[russkel]

@russkel no, I didn't look into this much further than what's in the PR. Feel free to work on it if you want!

Yeah I might have a go. Seems a good first ticket on this rosidl stuff, bit concerned about the PR sitting ignored though as has happened elsewhere.

[aprotyas]

Yeah, unfortunately I can't give time to this PR anymore, but I'd be happy to review and move forward things if you write some code.

[gavanderhoorn]

I haven't checked all of the related PRs and issues, but this seems like a much needed change.

It took me some time to realise byte[] is mapped onto list[bytes], which is at least counter-intuitive (it's documented, but still).

[aprotyas]

Almost reaching its 3rd cake day! I'd be very happy if someone could take over this PR.

[russkel]

Is bytearray more suitable for this given it is mutable?

[rus1ru]

Confirming this is still present on ROS 2 Jazzy (ros-jazzy-rclpy 7.1.11, official ros:jazzy Docker image), with a comparison that isolates it to byte[] / sequence<octet> specifically.

Publishing b"HELLO123" through both types in one node:

byte[]   (ByteMultiArray.data)  -> ('list', "[b'H', b'E', b'L', b'L', b'O', b'1', b'2', b'3']")
uint8[]  (UInt8MultiArray.data) -> ('array', "array('B', [72, 69, 76, 76, 79, 49, 50, 51])")

So uint8[] already arrives as a compact array('B'), while byte[] arrives as a Python list of one-element bytes objects - roughly 3x the object overhead per element plus per-element access cost for consumers.

Quantified impact from a pub/sub micro-benchmark we ran while evaluating alternatives (rclpy 7.1.11, same machine): a subscriber consuming 64 B ByteMultiArray messages tops out near ~11k msg/s against a publisher offering ~150k msg/s; per-message callback dispatch of these list-of-bytes payloads is a significant contributor alongside executor overhead.

Happy to help test a fix that maps sequence<octet> to bytes on deserialization.