Split of joint_state_publisher and joint_state_publisher_gui

This post is meant to serve as an announcement of a change in how joint_state_publisher works in Kinetic and Melodic.

For a while now, joint_state_publisher could be run in two separate modes; either as a standalone ROS node, or as a ROS node with an attached PyQt GUI useful for manipulating joints. This worked OK, but ended up dragging GUI package dependencies into the robot metapackage, which is prohibited.

To remedy this, we merged https://github.com/ros/joint_state_publisher/pull/31, which splits joint_state_publisher into two separate packages; joint_state_publisher (which just has the ROS node), and joint_state_publisher_gui (which has the ROS node and the attached GUI). For backwards compatibility, if joint_state_publisher is run with the use_gui parameter set to true, we’ll automatically launch joint_state_publisher_gui. In Noetic, the use_gui parameter and this backwards-compatibility portion will be removed.

@gavanderhoorn has kindly been fielding questions about this answers.ros.org, so we thought it would be good to announce this on a larger forum.

Please respond here if you have questions or comments about this.

4 Likes

To get it out of the way: why was joint_state_publisher_gui not made a dependency of joint_state_publisher, so there would be no breaking change (as the former would be automatically installed with the latter)?

1 Like

Good question. joint_state_publisher_gui is implemented by instantiating a JointStatePublisher object, and then passing that into the UI code. Thus, joint_state_publisher_gui depends on joint_state_publisher. We couldn’t then make joint_state_publisher depend on joint_state_publisher_gui, as that would create a circular dependency.

My little baby is all grown up and the name is still causing problems

3 Likes

The whole point of the split is to keep joint_state_publisher in the robot metapackage but remove joint_state_publisher_gui from it (since it contains a GUI dependency). Therefore the GUI package can’t be a dependency of the non-GUI package since that would make it part of the robot metapackage again.

I think the alternative split would have been to make joint_state_publisher_core and joint_state_publisher so that joint_state_publisher_core could be in the robot metapackage.

2 Likes

Just to clarify: I’m completely aware of why this was done. But seeing as @clalancette didn’t provide any rationale for it (for why the dependency was not added to prevent breakage), I thought I’d ask it here.