I don’t get why ROS2 nodes are incompatible between Humble and Jazzy (and in general).
I have had loads of problems when I wanted to send or receive messages between the two. I would assume that everything would just work: the messages are the same and surely DDS is a standard that is not affected.
2 Likes
ROS doesn’t introduce any breaking changes within a distribution (for example jazzy). This means your code will stay working, and this is a good thing!
But major changes have to be introduced someday, so it is normally chosen to introduce them in a new distribution. But this means that distributions are not compatibile unfortunately.
With the release of Iron, something called Type Description Distribution was introduced.
This makes multiple things possible, but for your case specifically: IIRC, it required changes to the way messages are serialised (additional metadata was added).
(then there’s also things like Change the GID storage to 16 bytes and significant differences in FastDDS between the two distributions you mention (2.6.x vs 2.14.x))
So even if message structure (and semantics) is identical, the bytestream exchanged is incompatible between anything Humble-and-older and Iron-and-newer.
while this is the typical response, it’s not entirely true. It really depends on a couple of factors and you can in fact exchange message cross-distribution (but not pre-iron ↔ post-iron, at least not easily).
Edit: obligatory please ask these sort of questions on robotics.stackexchange.com in the future @Conpleks.
6 Likes
Okay so we should request that companies that produce ROS2 compatible drivers for their sensors to at least support Iron, because Iron and later distributions have better compatablility?
At this stage we must choose between great sensor compatability (Humble) and the latest features (Iron/Jazzy).
1 Like
technically there are no guarantees about inter-distribution compatibility.
So to be safe, vendors should release drivers for all the ROS 2 distributions they want/are willing to support.
Relying on it-may-work-if-nothing-has-changed-or-changes-between-distributions is rather brittle and does not seem like good practice.
What I would personally find acceptable would be compatibility with LTS releases only. So Humble and Jazzy. That should not be too much work, while supporting the two main LTS releases at the moment.
Unfortunately binary compatibility, cross-distribution compatibility challenges come up repeatedly, but so far no solution has been found/implemented I believe.
PS: we’ve had a couple discussions around this topic in the previous year(s). I can’t find them immediately using the search. You may have better luck.
1 Like
Roughly, the recommendation here is that users NOT MIX NODES BETWEEN ROS DISTROS.
Will it work? Maybe? Maybe not? There are zero tests or guarantees for this type of development. The recommendation is to not even try. You are going to be swimming upstream the whole way if you try to mix distros.
If you end up getting stuck with a vendor that won’t upgrade their package please file an issue or send them a pull request. You’d be amazed at the number of people who will complain about a slowly upgrading vendor without contacting the vendor directly. Most vendors are fairly responsive to customer requests and upgrades between subsequent ROS distros (e.g. Iron to Jazzy) are usually fairly minor.
I’m always happy to help when these situations. If you have a vendor that won’t upgrade I’m always happy to talk with them and provide guidance.
3 Likes
Is there an official page or document I can refer to when talking with vendors?
A single phrase on any ros.org subpage will do.
So I don’t have to involve you every time Kathirne 
I would like to drop Running a subscriber on Humble with publishing from Jazzy / Rolling uses up all memory · Issue #797 · ros2/rmw_fastrtps · GitHub to the discussion. While I agree that breaking changes are necessary between distributions, the hazardous behavior as soon as there are mixed participants on the same domain ID, which can happen by accident, did actually surprise me.
@Conpleks searching for a package on index.ros.org should give you information about any ROS package (Released distributions, repository, issue tracker, etc).
If you rely on a package that has not been released for a distro, it’s often feasible to try building it from source in a newer distribution. Sometimes I was lucky and it was working directly, sometimes some small migrations are necessary. As @Katherine_Scott wrote, a pull request to the package’s repository makes most maintainers happy in that case.
If it’s working out of the box, opening an issue poking the maintainers to release for a newer distro will also not be a good way to get the package released, as re-releasing a package for a newer distro isn’t too much work for maintainers, if it just works.
2 Likes
I agree that this should not be the case. It should be relatively “safe” to intermix participants from different versions, but not expect communications between them.
That is not completely true. Some components, such as ros2_control and MoveIt, introduce API and/or ABI changes, or cause new warnings, within a distribution from time to time. But everything relying only on the client libraries (rclcpp, rclpy, …) should be fine.
Prior threads:
@Conpleks , looks to Cross-Vendor communication support is documented here, with the lack of Cross-Distro communication support being a derivative of that:
Tangentially related:
2 Likes
If inter-distribution is not supported then I think the packages should give a warning at build or launch. Like Android does with target SDK.
Unfortunately the problem exist not only between distributions but in some cases between different DDS RMWs too. Example is ROS Services DDS implementation. It is well captured here Service interoperability with FastRTPS · Issue #184 · ros2/rmw_cyclonedds · GitHub
ROS2 design talks about using DDS-RPC for Services but not all DDS vendors supported it at that time. As the result different RMW implemented it differently. As of Jazzy, only FastDDS finally moved to DDS-RPC. It would be nice if CycloneDDS also could switch to it, so then ROS Services interoperability would be possible between FastDDS and CycloneDDS inside same distribtion 
Thanks for the tip lambdaprime. That is a surprising amount of caveats. I would again request an official document that outlines these. If a company chooses to use ROS2 as their middleware this could lead to a lot of headaches.