[Documentation] [TitleIndex] [WordIndex

Topics vs Services vs Actionlib...

Topics

Topics...

Services

Services...

Actions

Actions...

When Topics Should be Remapped

Topic remapping is not just good for avoiding topic name collisions, but also for giving a node a "ROS API". This means a set of topics which are named in the context of the node.

For example, if you must connect the topic "out" of node A (the publisher) to the topic "in" of node B (the subscriber). The communication model requires that both A and B communicates via a single topic. A topic is fully defined by its name, so as long as the resolved topic name is the same and they are connected to the same ROS Master, the nodes will be able to communicate with each other.

Another point of view is the component writer point of view: one should not try to build complex topic names inside a node so that it matches the topic names of some other nodes. Very simple names (which are likely to create a name collision) are better as they will be renamed anyway! This is something many understand only long after using ROS. This pattern makes the whole "ROS API" of a node much easier to understand.

Publishing Spatial / Geometric Data

In general, coordinate frames should be published over TF, but there are numerous cases when this is not advisable.

Some cases when TF is less suitable:

TF is often useful for real-time, single-estimation data; this breaks down when one wants to apply a correction to a geometric relationship in the past (like when a loop closure occurs during SLAM, and this new information should be used to update the entire robot's path history), or when there are couple things estimating the same transform (like odometry and laser scan matching, or two robots looking at the same thing). There are some ways to make tf work in these cases, but they don't exhibit the same simplicity and elegance that tf shows for the real-time, single-estimation case.

Multi-Robot

Multi-robot tf over wifi, or tf over large-time-delay teleoperation won't behave optimally out of the box. However, a fairly lightweight fix is to use multiple /tf topics, like:

Bandwidth Considerations

Tf can easily consume bandwidth in the order of hundreds of kB/s, which can choke up connections in constrained scenarios (like RoboCup, where you have thousands of people/hundreds of teams/1-2 dozen leagues competing for Wi-Fi). If the goal is to monitor the estimated position of an autonomous robot, using tf can mean significant overhead, then an optional lower update rate tf topic for displaying the robot model in rviz could make sense for such situations.

Topic Publishing Patterns

When I have the same kind of data coming from multiple sources, should I use different topic names or have the origin of the data in the message?

One-to-One

One-to-Many

Many-to-One

Many-to-Many


2024-03-02 12:19