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

Latched Strings for URDF and SRDF #755

Closed
DLu opened this issue Oct 25, 2021 · 2 comments
Closed

Latched Strings for URDF and SRDF #755

DLu opened this issue Oct 25, 2021 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@DLu
Copy link
Contributor

DLu commented Oct 25, 2021

With the death of the one centralized parameter server to rule them all in ROS 2, it has become more cumbersome to have single instances of global parameters that everyone can use, i.e. often multiple nodes will need to individually load /robot_description into their parameter namespace.

robot_state_publisher gets around that problem by publishing a std_msgs::msg::String message with the entire URDF file that other files can then use.

Right now, rdf_loader requires that a parameter with the robot description is set AND that a separate parameter is set with the SRDF is set.

I find this most annoying when trying to plan from RViz, and you need to load the URDF/SRDF into the namespaces for both move_group and Rviz.

There are three different things that I think would make things easier:

  • RDFLoader allows for the parameter to be set for the URDF or reads it in from a topic.
  • RDFLoader publishes a std_msgs::msg::String with the SRDF
  • RDFLoader subscribes to the above String as an alternative to the parameter.

There's two tricky parts that I foresee:

  • Defining the RDFLoader constructor in a sufficiently concise way that allows for parameter or topic.
  • Making sure that a single instance RDFLoader doesn't subscribe to the topic it publishes.
@DLu DLu added the enhancement New feature or request label Oct 25, 2021
@henningkayser
Copy link
Member

@DLu those are some very reasonable thoughts. We have actually considered using a publisher in the past along with other options. However, the publisher method can have several shortcomings including that it's hard to sync if we want to support dynamic updates.

For reference:

In the long run, synced parameters instead of a topic are probably the cleanest solution. I'd encourage continuing this discussion in #615 or #208.

@tylerjw
Copy link
Member

tylerjw commented Nov 2, 2021

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

No branches or pull requests

3 participants