-
Notifications
You must be signed in to change notification settings - Fork 81
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
Conversation
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>
There was a problem hiding this 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) |
There was a problem hiding this comment.
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.
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
Stuck between a rock and a hard place here. If we do this, then by all rights
Good point. I've added the license stuff in 1db983d.
Actually, I think it is the other way around; Thanks for the review. |
Yeah that's pretty much what I'm suggesting. Rather than an
Good call 👍 |
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
All right, I've now updated it so that @sloretz @matthew-reynolds Ready for another round of review. |
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
There was a problem hiding this 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.
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>
There was a problem hiding this 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.
joint_state_publisher/README.md
Outdated
* `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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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>
@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>
There was a problem hiding this 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>
Thanks! Merging now that the buildfarm is turning over. |
@clalancette @sloretz Do you plan on updating REP 142/150 to add |
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 |
👍 |
I suppose we should also give a scan through the dependant packages on |
We're getting some questions on ROS Answers about this split (344992 fi). Should this change be announced on Discourse to reduce the surprise? |
@gavanderhoorn Thanks for fielding those ROS answers queries. I'll go ahead and make an announcement on Discourse. |
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 |
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 |
This PR splits joint_state_publisher into two packages:
joint_state_publisher
andjoint_state_publisher_gui
. Thejoint_state_publisher
package contains both code to be imported (theJointStatePublisher
class) along with a script that just runs the basic, non-GUI functionality ofJointStatePublisher
. Thejoint_state_publisher_gui
package contains the PyQt UI that allows one to control the movable joint via a UI, and depends on thejoint_state_publisher
package andJointStatePublisher
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 therobot
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 .