Closed pfranklincra closed 10 months ago
@pfranklincra The tf
topic is namespaced intentionally to follow the namespacing convention that the nav2 stack uses. For RViz, the launch files in clearpath_viz have a namespace argument that will automatically remap tf
and tf_static
, along with all other topics, to your robots namespace.
If you want to visualise multiple robots then you will require the relay node.
Got it, wasn't aware of the deprecation of tf_prefix.
Thanks!
Adds frame_prefix and tf_topic arguments to clearpath_platform_description, and more importantly changes the default tf topic for robot_state_publisher to
/tf
instead oftf
(effectively namespacing the tf topic).Affects users who are namespacing their robot.
I'm a little unclear on if you're accepting external PRs, or if I need to update versioning and whatnot myself.
Details:
Previously, if a robot is using a namespace (such as a200_0000), the robot_state_publisher publishes tf updates to/tf/tf/tf``` to visualize both at the same time.
<namespace>/tf```` (e.g.
/a200_0000/tf). RViz (and other tf utilities) are hardcoded to read tf updates from
/tf, which means that using those would require running RViz with a remapping to use
, and if using multiple robots with different namespaces, the use of a relay node to republish tf updates from
to
robot_state_publisher has a param called
frame_prefix
, which changes the published tf links to<frame_prefix>/<link_name>
. RViz RobotModel Display also contains an option to set the frame_prefix, so that it can still be used to visualize the robot model. Multiple RobotModelDisplays can be set to different frame_prefixes to display multiple vehicles on the /tf topic.This assumes that if one is using a namespace, that should be used to namespace the tf_links, and so the default value for frame_prefix is
<namespace>/
. In testing, setting the frame_prefix to/
(when namespace is not set) works with RViz, although I'm not sure if it will cause problems with other tf utilities (instead of links being namedbase_link
, they are named/base_link
).The use case I could come up with for having separate tf topics is when trying to avoid using the network if multiple vehicles are on the same ROS_DOMAIN_ID. Using the default tf topic means any robot using tf will subscribe to messages from ALL robots using tf. The extra argument for setting the tf_topic means that robots could potentially only use tfs from themselves and not add network burden by existing. I'm not sure if this is a use case that is widely used, but I figured it might be nice to be supported. My assumption is that the average user would rather have RViz and other tf utilites not require remapping or relay nodes to visualize robots on the network.