forked from frankaemika/franka_ros
-
Notifications
You must be signed in to change notification settings - Fork 1
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
Stop re-publishing joint states #1
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
No need to declare an intermediate property
... to hide them in the final URDF
... avoiding code duplication
... to clarify that this node requires the remapping.
The robotNamespace is conceptually different from arm_id. While the latter just acts as a name prefix for links and joints, the <robotNamespace> tag specifies the name of the ROS namespace, which is used for key robot components like the joint_states topic, the controller_manager, etc. To allow for an empty namespace, the default needs to be specified as empty. Otherwise, i.e. having a non-empty default, specifying ns:="" on the commandline will fall back to the default despite an (empty) value was provided.
By default, we don't start in a namespace to match the real-robot behavior. Unfortunately, we cannot just specify an empty ns="" in roslaunch, but we need to distinguish the two cases empty/non-empty namespace. To avoid code duplication, the relevant code was factored out into panda_ns.launch.xml, which is include w/ or w/o a namespace. The file-ending is deliberatively choosen as .launch.xml to hide the file from bash completion.
LGTM. I was not aware of these performance issues. Thanks a lot for pointing that out. |
The proposed approach has its drawbacks too:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Re-publishing
joint_states
viajoint_state_publisher
(a python app) is highly inefficient.IMO remapping would be the right way to go instead - as long nobody needs the published topics on the namespace
franka_state_controller
/franka_gripper
.Also, I dropped re-publishing
joint_states_desired
completely.@gollth and @rickstaa, what do you think?
As this is just a draft and builds on frankaemika#187, I filed the changes in my fork for now.