Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split jsp and jsp gui #31

Merged
merged 13 commits into from
Jan 13, 2020
Merged

Split jsp and jsp gui #31

merged 13 commits into from
Jan 13, 2020

Conversation

clalancette
Copy link
Collaborator

This PR splits joint_state_publisher into two packages: joint_state_publisher and joint_state_publisher_gui. The joint_state_publisher package contains both code to be imported (the JointStatePublisher class) along with a script that just runs the basic, non-GUI functionality of JointStatePublisher. The joint_state_publisher_gui package contains the PyQt UI that allows one to control the movable joint via a UI, and depends on the joint_state_publisher package and JointStatePublisher class.

Doing this is desirable for a few reasons, mainly to slim down joint_state_publisher and remove the Qt dependencies from the robot metapackage (see ros/metapackages#28 for details).

I am unsure where to target this PR. This is definitely a breaking change in that users who just install/launch joint_state_publisher will no longer have GUI functionality available. So I would usually target noetic with this. However, I think that removing the GUI dependencies from the robot metapackage in kinetic and melodic is important, so I'm currently targeting this at kinetic-devel. I'm definitely open to discussing this further.

This also fixes #21 .

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
This will be moved to a separate package.

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
@clalancette clalancette mentioned this pull request Dec 19, 2019
Copy link

@matthew-reynolds matthew-reynolds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're right to target Kinetic & Melodic, though I think we'd be better off with a smoother migration as described in my comment. Then for Noetic we can drop the forwarding altogether.

Couple other comments:

Since you're restructuring and creating a bunch of new files, is this a good opportunity to add license header comments? It appears the other former robot_model packages all have the expected 3-clause BSD license w/ Willow Garage as the copyright holder.

Don't think the screenshot.png needs to be copied over to the new package.

use_gui = get_param('use_gui')
if use_gui is not None:
rospy.logerr('GUI is no longer supported by this package; install and run joint_state_publisher_gui')
sys.exit(1)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I strongly believe we should approach this the same way we're working on removing the GUI dependencies from actionlib in ros/actionlib#157.

That is, rather than failing outright, attempt to minimize the breaking change by searching for and launching joint_state_publisher_gui if possible, with a warning telling users about the change. In the case that the joint_state_publisher_gui package isn't found, print an error and exit(1) as you've done here.

README.md Outdated Show resolved Hide resolved
joint_state_publisher_gui/CMakeLists.txt Outdated Show resolved Hide resolved
joint_state_publisher_gui/package.xml Outdated Show resolved Hide resolved
joint_state_publisher_gui/package.xml Outdated Show resolved Hide resolved
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
@clalancette
Copy link
Collaborator Author

I think you're right to target Kinetic & Melodic, though I think we'd be better off with a smoother migration as described in my comment. Then for Noetic we can drop the forwarding altogether.
That is, rather than failing outright, attempt to minimize the breaking change by searching for and launching joint_state_publisher_gui if possible, with a warning telling users about the change. In the case that the joint_state_publisher_gui package isn't found, print an error and exit(1) as you've done here.

Stuck between a rock and a hard place here. If we do this, then by all rights joint_state_publisher should have a dependency on joint_state_publisher_gui. Since joint_state_publisher_gui already has a dependency on joint_state_publisher, we end up with a circular dependency. On the other hand, if we don't do this, then we end up with potentially surprising results as you point out. I guess if we have a graceful fallback option, we can just live with the incorrect dependency hierarchy. I can take a look at doing that after the holidays.

Couple other comments:

Since you're restructuring and creating a bunch of new files, is this a good opportunity to add license header comments? It appears the other former robot_model packages all have the expected 3-clause BSD license w/ Willow Garage as the copyright holder.

Good point. I've added the license stuff in 1db983d.

Don't think the screenshot.png needs to be copied over to the new package.

Actually, I think it is the other way around; joint_state_publisher itself no longer needs it (since it is a screenshot of the GUI). So I've moved the screenshot over to the GUI package.

Thanks for the review.

@matthew-reynolds
Copy link

I guess if we have a graceful fallback option, we can just live with the incorrect dependency hierarchy

Yeah that's pretty much what I'm suggesting. Rather than an exec_depend on joint_state_publisher_gui, we have a sort of "soft dependency" where we instruct the user to install the package. Definitely not a clean dependency hierarchy, but it smooths out the migration. Especially since I suspect the "soft dependency" will resolve for most users, since if they're using the GUI they're likely on a desktop metapackage install anyways.

Actually, I think it is the other way around

Good call 👍

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
@clalancette
Copy link
Collaborator Author

All right, I've now updated it so that joint_state_publisher has a "soft" dependency on joint_state_publisher_gui, and will attempt to launch the latter if use_gui is set to True. This mimics backwards-compatible behavior with what exists in Kinetic and Melodic. Assuming we merge this PR, I intend to make a new noetic branch where we remove this workaround.

@sloretz @matthew-reynolds Ready for another round of review.

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
Copy link

@matthew-reynolds matthew-reynolds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for that change, looks great. import sys could be moved within the if use_gui: block, but then we've got imports in 3 different places, so I like what you've done by leaving it at the top.

Found one last question, see below.

joint_state_publisher/package.xml Outdated Show resolved Hide resolved
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
We get it implicitly through the catkin dependency.

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
Copy link
Contributor

@sloretz sloretz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partial review, coming back to this later.

* `use_smallest_joint_limits` (bool) - Whether to honor `<safety_controller>` tags in the URDF. Defaults to True.
* `source_list` (array of strings) - Each string in this array represents a topic name. For each string, create a subscription to the named topic of type `sensor_msgs/JointStates`. Publication to that topic will update the joints named in the message. Defaults to an empty array.
* `zeros` (dictionary of string -> float) - A dictionary of joint_names to initial starting values for the joint. Defaults to an empty dictionary, in which case 0.0 is assumed as the zero for all joints.
* `dependent_joints` (dictionary of string -> dictionary of 'parent', 'factor', 'offset') - A dictionary of joint_names to the joints that they mimic; compare to the '<mimic>' tag in URDF. A joint listed here will mimic the movements of the 'parent' joint, subject to the 'factor' and 'offset' provided. The 'parent' name must be provided, while the 'factor' and 'offset' parameters are optional (they default to 1.0 and 0.0, respectively). Defaults to the empty dictionary, in which case only joints that are marked as '<mimic>' in the URDF are mimiced.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the preview, '<mimic>' renders as ''. Use backticks instead?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will try to fix that.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 3e59f5a

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
This can happen if something is published to the joint_state_publisher
source_cb, so in that case we need to update the GUI.

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
@clalancette
Copy link
Collaborator Author

@sloretz Thanks for the partial review, I've fixed the issues you've identified. Ready for complete review/second round of review.

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
Copy link
Contributor

@sloretz sloretz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with one nit. Thanks for keeping the amount of unrelated cleanup to a minimum. It made diffing/reviewing pretty easy.

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
@clalancette
Copy link
Collaborator Author

Thanks! Merging now that the buildfarm is turning over.

@clalancette clalancette merged commit d5b5c05 into kinetic-devel Jan 13, 2020
@clalancette clalancette deleted the split-jsp-and-jsp-gui branch January 13, 2020 18:17
@matthew-reynolds
Copy link

matthew-reynolds commented Jan 28, 2020

@clalancette @sloretz Do you plan on updating REP 142/150 to add joint_state_publisher_gui to the desktop metapackage? Happy to provide a PR if this is your plan.

@clalancette
Copy link
Collaborator Author

clalancette commented Jan 31, 2020

@clalancette @sloretz Do you plan on updating REP 142/150 to add joint_state_publisher to the desktop metapackage? Happy to provide a PR if this is your plan.

As far as I can tell, REP-142 doesn't need to be updated. It doesn't include joint_state_publisher in the robot metapackage, and I don't think we should change that this late in its lifetime.

REP-150 is obviously out-of-sync with what is in https://github.com/ros/metapackages; I'll submit a PR to update that soon.

Arg, never mind, I was confused. I forgot about the soft dependency thing.

So it is still the case that REP-142 doesn't have joint_state_publisher at all, so I don't think we need to do anything there. REP-150 should indeed be updated to add joint_state_publisher_gui to the desktop metapackage; I'll open a PR for that soon.

@clalancette
Copy link
Collaborator Author

@matthew-reynolds
Copy link

REP-142 doesn't have joint_state_publisher at all, so I don't think we need to do anything there

jsp is pulled in via robot_model (in the robot metapackage) and urdf_tutorial (in the desktop_full metapackage). Seems risky to not add jsp_gui to desktop since previously every install from robot upwards contained the gui.

REP-150 should indeed be updated to add joint_state_publisher_gui to the desktop metapackage

👍

@matthew-reynolds
Copy link

matthew-reynolds commented Jan 31, 2020

I suppose we should also give a scan through the dependant packages on jsp and update them accordingly (ie. urdf_tutorial uses the jsp gui, but depends only on jsp). I will get started on this.

@gavanderhoorn
Copy link

gavanderhoorn commented Feb 25, 2020

We're getting some questions on ROS Answers about this split (344992 fi).

Should this change be announced on Discourse to reduce the surprise?

@clalancette
Copy link
Collaborator Author

@gavanderhoorn Thanks for fielding those ROS answers queries.

I'll go ahead and make an announcement on Discourse.

@ros-discourse
Copy link

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/split-of-joint-state-publisher-and-joint-state-publisher-gui/12997/1

@ros-discourse
Copy link

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/fast-forward-merging-rosbag2-master-api-to-foxy/18927/15

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

split gui dependencies
5 participants