Revision history [back]

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.

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 make the connection failure go away. 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.

• Upgrade your robot to Noetic, recompile pre-compiled nodes as necessary. 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: Any clients still using kinetic cannot now connect with the robot.

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.

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 make the connection failure go away. 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.
• Upgrade your robot to Noetic, recompile pre-compiled nodes as necessary. UPSIDE:
  • UPSIDE Maximally efficient end result, since both ends of the system are now on Noetic. DOWNSIDE: Noetic.
  • DOWNSIDE Potentially significant intervention for robots in the field - installing Noetic even on a strong internet connection takes a little while. DOWNSIDE: while.
  • DOWNSIDE Any clients still using kinetic cannot now connect with the robot.
  • 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 the above, 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 topic name, since we can't override the existing topic. Noetic users have an extra documentation paragraph to read to explain where the topic is available, and we can anticipate support calls arising from users attempting to connect to the old topic with the new format.
  • Overall, the simplest solution for ROS adepts, but a little challenging perhaps for more general users.
• Import the old (kinetic) BatteryState format into the client software suite, and modify client nodes to use this internalised version of the format rather than the one provided with ROS.
  • UPSIDE Maximally efficient end result.
  • UPSIDE No changes needed to the robot.
  • UPSIDE No separate translation node needs to be run.
  • DOWNSIDE Users will have to be told to use this internal format when connection (robot.BatteryState rather than sensor_msgs.BatteryState), else they'll be on to support asking why they can't connect.

I think that covers the options.

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.

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 make the connection failure go away. 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.
• Upgrade your robot to Noetic, recompile pre-compiled nodes as necessary. 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 Any clients still using kinetic cannot now connect with the robot.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 the above, 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 topic name, since we can't override the existing topic. Noetic users have an extra documentation paragraph to read to explain where the topic is available, and we can anticipate support calls arising from users attempting to connect to the old topic with the new format.
  • Overall, the simplest probably the most elegant solution for ROS adepts, but a little challenging perhaps for more general users.
• Import the old (kinetic) BatteryState format into the client software suite, and modify client nodes to use this internalised version of the format rather than the one provided with ROS.
  • UPSIDE Maximally efficient end result.
  • UPSIDE No changes needed to the robot.
  • UPSIDE No separate translation node needs to be run.
  • DOWNSIDE Users will have to be told to use this internal format when connection (robot.BatteryState authoring their own nodes that connect to the topic (robotsdk.BatteryState rather than sensor_msgs.BatteryState), else they'll be on to support asking why they can't connect.

I think that covers the options.

Policy in ROS versioning is that communication Communication of topics between nodes built on different versions of ROS (e.g. kinetic <--> noetic) ought seems generally to work provided the format of the messages is the same at both ends.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 topic name, since we can't override the existing topic. Noetic users have an extra documentation paragraph to read to explain where the topic is available, and we can anticipate support calls arising from users attempting to connect to the old topic with the new format.
  • Overall, probably the most elegant solution for ROS adepts, but a little challenging perhaps for more general users.
• Import the old (kinetic) BatteryState format into the client software suite, and modify client nodes to use this internalised version of the format rather than the one provided with ROS.
  • UPSIDE Maximally efficient end result.
  • UPSIDE No changes needed to the robot.
  • UPSIDE No separate translation node needs to be run.
  • DOWNSIDE Users will have to be told to use this internal format when authoring their own nodes that connect to the topic (robotsdk.BatteryState rather than sensor_msgs.BatteryState), else they'll be on to support asking why they can't connect.

I think that covers the options.