Are ROS2 messages guaranteed to be received by a Subscriber in the same order they were published?

edit

However, I can't find any mention anywhere about the Ordering of messages.

That's correct, we don't expose that QoS setting from DDS, but if it's something you need repeatedly and there's a compelling reason to move it out of "user space" and into the "middleware space" (like performance), then we can consider adding it. To start that process I'd make an issue on the ros2/ros2 or ros2/rmw issue trackers explaining your case for it.

My understanding is that RTPS guarantees that messages are published in the order they are queued but I couldn't work out whether this also means that all subscribers are guaranteed to receive those messages in the same order as well.

My understand is that they are not guaranteed to be received in order. This is basically a performance trade-off. Especially if you're using "reliable" rather than "best effort". For example, consider you received sequence number 1, 2, and 4. How long do you wait for 3 before you deliver 4?

This is why DDS let's you configure the behavior. For example, here's the RTI Connext documentation for the ordered access kind of "presentation" QoS:

https://community.rti.com/static/docu...

I link to their documentation only because it's easy to link to, but the other DDS implementations also support it I believe (though I'm not sure about pure RTPS implementations).

There is also some flexibility as to how this is implemented. For example, this page on the CoreDX DDS implementation's page says that they will not deliver messages out of order in best effort:

http://www.twinoakscomputing.com/core...

So I think the best bet (and we should clarify this in our API documentation -- something else we could use help with :D) is to assume they are not delivered in order.

We also removed the "sequence number field" from the standard ROS Header message type ( https://github.com/ros2/common_interf... ), with the idea that it was ill formed and that the middleware should give this information outside of the message data. Unfortunately we haven't exposed this information from the middleware yet either (something we could use help with perhaps), but ideally the sequence numbers would be unique and monotonic for each separate publisher (part of the reason a sequence number in the message data was ill formed).

Moreover, the ROS2 node's callback that is registered to process a message that has been subscribed to on a given topic must also be called in the same order that the message was published (i.e. not necessarily in the same order it was received at least in my understanding..).

I don't understand why you think it "must also be called in the same order that the message was published". As far as I know, that's not a requirement or guarantee of the ROS callbacks. Delivery in order is the typical behavior, but again not required. In general they are ... (more)