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

Stop re-publishing joint states #1

Closed
wants to merge 9 commits into from
Closed

Conversation

rhaschke
Copy link
Owner

Re-publishing joint_states via joint_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.

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.
@rickstaa
Copy link

LGTM. I was not aware of these performance issues. Thanks a lot for pointing that out.

@rhaschke
Copy link
Owner Author

The proposed approach has its drawbacks too:

  • It breaks existing software relying on topics franka_state_controller/joint_states and/or franka_gripper/joint_states
  • joint_states messages from arm and gripper are published both to the same topic, so we cannot easily distinguish them anymore (w/o looking at the message of course)
  • the variable message format (7 vs. 2 joints) might confuse existing software, e.g. rqt_plot

@rhaschke rhaschke closed this Nov 7, 2021
@rhaschke rhaschke deleted the publish-joint-states branch November 7, 2021 01: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.

2 participants