would it also be easy to use this to create bridges between ROS 2 distributions as well
We tried combining Dashing and Eloquent and that worked fine. As they all use DDS, I would expect that it also works with Foxy. Did you already try to combine Dashing and Foxy?
As @Wilco says, you should not need any kind of bridge between any of Dashing, Eloquent and Foxy. All three are compatible at the communications level.
You can’t rely on it for any future distributions because we never guarantee compatibility between distributions. For example, the std_msgs are deprecated and are going to go away in a future distribution so you would have to provide them yourself to be compatible with applications running on old distributions that use messages from that package. However for Dashing, Eloquent and Foxy applications generally work together.
I believe @gavanderhoorn’s question above really gets to the point, especially on user aspect. So I just created the comparison table for mostly what the user gets?. I might be wrong on some points, so let me know if you find anything I got wrong. that would be really appreciated.
So it sounds like, in general, bridges still may be necessary to connect ROS 2 nodes from different distributions.
That or there needs to be a way to force all nodes in a system to switch to a common distribution. That seems like it might be difficult, though, in a system with lots of nodes on lots of machines with lots of users. There may not be a common distribution that would work with every node and changing all of the nodes might be tricky even if there was.
What would be the best way to manage such a system? Perhaps ROS messages are not the most appropriate format for distributing data in such large diverse systems, but if they are not, what is?
Just for clarification: there are two different types of potential incompatibilities for the communication across ROS distributions:
Changed message / service / interface definitions.
Changes in the underlying protocol. E.g. in ROS Bouncy we switched from using DDS partiions to namespaced topic names (see notes). If in the future a conceptional shortcoming like ros2/ros2#921 is addressed that would likely also imply that services will be incompatible with older distros.
If nodes from several distributions are running on the same network they will discover and see each other’s topics correct?
Is there any way to tell to which distribution a message or topic belongs? So, for example, a foxy node would not try to subscribe to an image topic from a bouncy node with the same name? Or would you have to differentiate them manually by using different topic names or domain ids?
If there is a chance that nodes from different distributions will connect to the same network and interfere with each other, would it be safer to separate them with topic names or domain ids?
I’m not sure about what you mean by changed semantics, since I’m not an expert in ROS 2 actions; anyway, if it concers to the action types names, remapping can be used to solve the differences between ROS1 and ROS2 naming conventions.
As for the state machine, it would be handled automatically by SOSS; SOSS is fed with the IDL files generated by rosidl from msg/srv/actions files. If I’m not wrong, resulting IDLs from action files already contain the state-related fields in their definition, so the transformation would be done using xTypes and the information would be available on the other side. Anyway, I understand it is tedious for the user to define three services and two topics for each action in the YAML file, specially if they are autogenerated; that is why we could address some improvements to include a specific action section in the SOSS configuration YAML semantics.
@tomoyafujita nice summary! Regarding one of SOSS’ biggest flaws: yes, we do not support dynamic bridging (yet), but it can be easily achieved thanks to the integration with xTypes dynamic types. A dedicated API and implementation for dynamic bridging entities creation/destruction is on the roadmap for 1st semester 2021.
Mapping the topics is a necessary part of bridging actions, but seems to be only partial. I haven’t looked into how SOSS would use the IDL files to figure out the state machine differences though. Is that supported?
This is starting to get more-and-more off-topic, but:
Afaik there is no documented best practice for this.
Users have always been encouraged to not use std_msgs/Int* or std_msgs/String, but to create semantically meaningful messages. A topic carrying a String doesn’t tell you anything about what its intended use is, nor how the message should be interpreted (other than as a plain String of course).
So usage of std_msgs is discouraged as there are probably better message types you can use, and you also don’t need to use it, as fields in other messages (including your own) should just use the primitive types (ie: string, uint8, etc) instead of their wrapped versions from std_msgs (ie: std_msgs/String, std_msgs/UInt8, etc).
As to some context (almost in some sort-of chronological order):
I wasn’t aware of this either. So what do you do to replace a std_msgs/Trigger or Bool, where the topic name tells you everything you need to know about the message/intention?
It does seem a little excessive to have to create new messages just to change a field name for those times when the topic name might expressive enough.
Topic name really only means something to humans and iscan be very ambiguous.
A compiler or a tool assisting composition of ROS applications cannot determine whether the std_msgs/Float32 from the topic /coffee_temperature is semantically compatible with the topic /gas_throttle which also accepts std_msgs/Float32 messages.
To a human, using the temperature of a cup of coffee to control the gas throttle of a car would not make much sense. To a machine, this would need several layers of AI which do not exist at this time, so a check for compatible topic types would be much easier to implement and actually feasible.
That’s what this is about.
But even for humans it would be better to look at a topic and seeing it carry GasThrottleSetpoint messages than plain Float32s.
Ok, I understand. I believe the answer to that scenario is having the ability to perform custom transformations. However still not implemented, they are also on the roadmap and will allow users to specifically specify how certain types are translated from one world to another.