I am currently preparing a presentation on ROS2 at Chili Con Chaos 2024 and would also like to talk about the DDS layer. I have now found the official design article on this and I am interested in how much of it has ended up in reality. From what I’ve read, probably a lot. I am therefore particularly interested in what has not ended up in real implementations of the dds. Is anyone familiar with this and/or, if in doubt, can tell me which sources can be consolidated?
The big boon for DDS right now for me is that the services are treated as an implementation detail, which means that if you use different DDS vendors, pub/sub works but services and actions aren’t guaranteed to work.
. There is currently an RPC specification being considered for ratification in the OMG DDS working group, and several of the DDS vendors have a draft implementation of the RPC API. It is not clear, however, whether this standard will work for actions, but it could at least support non-preemptable version of ROS services. ROS 2 could either implement services and actions on top of publish-subscribe (this is more feasible in DDS because of their reliable publish-subscribe QoS setting) or it could use the DDS RPC specification once it is finished for services and then build actions on top, again like it is in ROS 1. Either way actions will be a first class citizen in the ROS 2 API and it may be the case that services just become a degenerate case of actions.
Thus, when I try doing a heterogenous fleet of vehicles, even if they are all using the same ROS distro, if they use different vendors (say one product needs a certain certification that only RTI offers), then it’s not compatible. This is particularly annoying because some software projects can’t use ROS 2 because it uses C++17, and they vendor lock to a certain DDS vendor, and then another product uses a different vendor and now you only have pub/sub.
3 Likes