ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

How to receive standard message that has changed format in noetic?

asked 2020-10-19 16:28:37 -0600

benjmitch gravatar image

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.

edit retag flag offensive close merge delete

Comments

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.

benjmitch gravatar image benjmitch  ( 2020-10-19 19:29:34 -0600 )edit

The issue #140 explicitly suggests that the change should be accompanied by documentation of the migration requirements,

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:

both for requirements for their code base

this is the first part I mention

bag migration rules for logged data.

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/BatteryState messages from your robot? So you're ...(more)

gvdhoorn gravatar image gvdhoorn  ( 2020-10-20 02:56:26 -0600 )edit

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)

benjmitch gravatar image benjmitch  ( 2020-10-20 07:56:51 -0600 )edit

I didn't mean to criticise a lack of documentation to be clear

I did not take your comment as criticism. Just explained how I believe you should understand @tfoote's comment in the issue you linked.

I am not aware of the ROS policy on communication across versions

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.

However, I've noticed that it seems to work

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.

Yes, I only want to make the issue transparent to our Noetic customers. Yes, they ...

(more)
gvdhoorn gravatar image gvdhoorn  ( 2020-10-20 08:02:18 -0600 )edit

.. 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 AnyMsg can be used for this.

gvdhoorn gravatar image gvdhoorn  ( 2020-10-20 08:13:01 -0600 )edit

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.

benjmitch gravatar image benjmitch  ( 2020-10-20 08:27:47 -0600 )edit

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.

gvdhoorn gravatar image gvdhoorn  ( 2020-10-20 08:30:32 -0600 )edit

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.

benjmitch gravatar image benjmitch  ( 2020-10-20 08:45:22 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2020-10-21 15:19:10 -0600

benjmitch gravatar image

updated 2020-10-29 01:10:06 -0600

Communication of topics between nodes built on different versions of ROS (e.g. kinetic <--> noetic) seems generally to work provided the format of the messages is the same at both ends. However, gvdhoorn describes the official policy as "there are no guarantees, if it works, it's nice, but don't expect nor assume it to work" (see comment to this answer).

The message type in question - sensor_msgs/BatteryState - changed between versions melodic and noetic (fields were added for battery temperature). ROS nodes on the robot (pre-installed and/or pre-compiled against kinetic) publish messages in the old BatteryState format. ROS nodes running on a client under noetic look up the format for BatteryState when they are compiled (C++) or executed (Python), find the new format, and thus cannot connect to topics using the old BatteryState format because the two are not identical. There is no automatic translation between earlier and later versions of messages.

There is no magic trick to apply here to retro-fit support for noetic in a way that is transparent to the end users. Rather, you need to choose from one of a list of practical solutions, which are detailed here. Each of them resolves the format mismatch in a different way, and which you choose would depend upon the constraints of your application.

  • Insist that your users stick with Kinetic. Self-explanatory.
    • UPSIDE Transparent to end users.
    • UPSIDE Maximally efficient end result, since both ends of the system are now on Kinetic.
    • DOWNSIDE Users cannot upgrade to noetic (they will be unable to connect).
    • Overall, this doesn't really solve anything.
  • Upgrade your robot to Noetic, recompile pre-compiled nodes as necessary.
    • UPSIDE Transparent to end users.
    • UPSIDE Maximally efficient end result, since both ends of the system are now on Noetic.
    • DOWNSIDE Potentially significant intervention for robots in the field - installing Noetic even on a strong internet connection takes a little while.
    • DOWNSIDE Users must all upgrade to noetic (kinetic users can no longer connect).
    • Overall, this sacrifices generality (supporting all end users) for a probably unmeasurable performance benefit.
  • Hack your robot kinetic install to use the new BatteryState format. Install the appropriate headers and recompile, and/or install the appropriate Python message descriptions.
    • Essentially same results as upgrading the robot to noetic, but after much less intervention. Also means you've now got a hacked-around ROS install which could snowball into a problem if there are more updates later on.
  • Provide a ROS node to your users that performs translation between the old format and the new format, republishing the topic on a modified topic name using noetic's format.
    • UPSIDE No changes needed to the robot.
    • UPSIDE Simple to implement off-board also.
    • DOWNSIDE Users have an extra responsibility (run this node before you do anything else, only if you are using Noetic). Obvs could be automated, depending on usage.
    • DOWNSIDE The new topic will be in the Noetic format, ready for hassle-free noetic subscriptions, but will be in a new place, a modified ...
(more)
edit flag offensive delete link more

Comments

Policy in ROS versioning is that communication between different versions (e.g. kinetic <--> noetic) ought to work provided the format of the messages is the same at both ends.

This might be a bit too optimistic: official answer is always "there are no guarantees, if it works, it's nice, but don't expect nor assume it to work".

gvdhoorn gravatar image gvdhoorn  ( 2020-10-27 05:49:58 -0600 )edit

And please update your answer with whatever option you chose in the end.

That would be valuable information.

Especially if you could comment on what worked and didn't work.

gvdhoorn gravatar image gvdhoorn  ( 2020-10-27 05:50:45 -0600 )edit

Question Tools

2 followers

Stats

Asked: 2020-10-19 16:28:37 -0600

Seen: 728 times

Last updated: Oct 29 '20