How to receive standard message that has changed format in noetic?
Hi,
One of our products is built on ROS kinetic and publishes the BatteryState message. All is well when receiving from a client that is also at kinetic.
Now, some of our clients are now living in 2020, and thus are using noetic, and the BatteryState message has been augmented (changelog). My question is - what is the intended way of us handling this format change so as to support both kinetic users (before the change) and noetic (after).
We would prefer not to upgrade the robots to noetic, since many users are still on kinetic. Even were we to choose this route, it would not be straightforward to organise the update in the field. But we could make a configuration change to the robots if required.
We would also be able to supply (for example) the older BatteryState message to new users - but I can't imagine how to connect it up so it is loaded correctly, since the incoming messages from the robot are tagged as type sensors_msgs/BatteryState, which is already defined by noetic. Could that connection process be interrupted somehow...?
The issue #140 explicitly suggests that the change should be accompanied by documentation of the migration requirements, but I can't find where this would be (it's not on the common_msgs documentation site, either the FAQ or the changelog) and don't really know where to look. So if that exists, please could somebody point me at it?
Thanks.
Clarification: It is possible to write a client that subscribes to these topics from noetic by providing the kinetic (legacy) message format and using e.g. rospy.Subscriber(topicname, legacymsgtype, ...). However, this would require changes to client-authored code. The aim is to achieve a transparent fix-up, if possible.
what I believe @tfoote means to say (in his comment on the issue you link) is that the breakage should be clearly documented and if required, should explain to users how they should use the new version. It does not necessarily include documentation on how to have two ROS versions with different versions of the message communicate.
From the comment:
this is the first part I mention
this would be only for
.bags (not live pub-sub).As to your question: what are you specifically trying to do? I'm assuming you're looking to provide some sort of convenience node to your Noetic customers which allows them to still receive
sensor_msgs/BatteryStatemessages from your robot? So you're ...(more)I see. I didn't mean to criticise a lack of documentation to be clear,, just wondered if there was some that I had not found. I am not aware of the ROS policy on communication across versions, in general, I can't find a statement on this. However, I've noticed that it seems to work, and that the message format/parse arrangements clearly support it, and this change is the first exception to that that I've encountered. Yes, I only want to make the issue transparent to our Noetic customers. Yes, they would only receive BatteryState messages (and a custom message that includes BatteryState). We ship various example ROS nodes to them, and as things stand, as I understand it, we would have to ship different code for those using Kinetic and those using Noetic, and - in addition - we would have to advise them to use our ...(more)
I did not take your comment as criticism. Just explained how I believe you should understand @tfoote's comment in the issue you linked.
The 'official' standpoint has always been: there are no guarantees. It may work, but there are no guarantees, and there is a good chance it won't, as breaking changes are introduced between ROS versions.
You're affected by one of those breaking changes.
It can work, but generally only when the messages haven't changed between the two ROS versions you're trying to use. As that premise is not true here, things don't work.
(more).. using some tricks with typing in a C++ node. Python could also work though. In essence, you just need a node which can subscribe to a topic carrying the old version of the message, and publish to a topic which carries the new version.
The node would essentially be a relay.
It might even be possible to do this with something like ros_type_introspection and a bit of custom code (see the tutorials). That would not need the old version of the message definition at all. You'd just have to write some code able to copy over the values of the fields from the old incoming message to an instance of the new message definition, and then publish it.
Python would probably also be possible, but I'm not sure the
AnyMsgcan be used for this.Thanks, very helpful to my understanding. A relay node would have to move the signal to a different topic name, right? E.g. sub(batterystate), pub(batterystate2). So users would in that case have to (a) run the relay node and (b) subscribe to a different topic name to receive the translated message. I can see that would be helpful in some circumstances, but it doesn't sound easier on them than asking them to use a custom message type. I guess we're concluding that it isn't possible to do this transparently for them - and I'm solidifying my understanding of why.
No, I don't believe this can be done in any other way than either updating code on your robot (ie: make it publish the new msg type, which would be possible without updating everything), or running something which transforms the messages from one version to the other.
There is a lot possible with flexibly typed Python scripts, introspection and topic remapping, but as soon as the message data has left the host it's published on, you cannot change it unless there is a node which receives it, deserialises it, changes it and republishes.
Would it really be so bad to have to run one additional relay node if you are wanting to use a newer version of ROS with a product which does not support that newer version (yet)? Sounds like a small price to pay to me.
But I may not fit your regular customer profile.
It's not unreasonable, but - no - you don't fit the profile ;), hence my looking for a way to make it transparent. Thanks for your help, I'll try my best to write up the different options in an answer later on.