Contents
Topics vs Services vs Actionlib...
Topics
Topics...
- Should be used for continuous data streams (sensor data, robot state, ...).
- Are for continuous data flow. Data might be published and subscribed at any time independent of any senders/receivers. Many to many connection. Callbacks receive data once it is available. The publisher decides when data is sent.
Services
Services...
- Should be used for remote procedure calls that terminate quickly, e.g. for querying the state of a node or doing a quick calculation such as IK. They should never be used for longer running processes, in particular processes that might be required to preempt if exceptional situations occur and they should never change or depend on state to avoid unwanted side effects for other nodes.
- Simple blocking call. Mostly used for comparably fast tasks as requesting specific data. Semantically for processing requests.
Actions
Actions...
- Should be used for any discrete behavior that moves a robot or that runs for a longer time but provides feedback during execution.
- The most important property of actions is that they can be preempted and preemption should always be implemented cleanly by action servers.
- Actions can keep state for the lifetime of a goal, i.e. if executing two action goals in parallel on the same server, for each client a separate state instance can be kept since the goal is uniquely identified by its id.
- Slow perception routines which take several seconds to terminate or initiating a lower-level control mode are good use cases for actions.
- More complex non-blocking background processing. Used for longer tasks like execution of robot actions. Semantically for real-world 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:
- For efficiency, in situations where there are a large number of frames, most of which are only of interest to a few subscribers.
- The coordinate frames naturally form a graph rather than a tree (e.g., a slam graph).
- There is frequent re-parenting of frames (e.g., a robot which is localized w.r.t. a changing local frame rather than a global one)
- The transformations include additional information such as uncertainty estimates not present in the TF message type.
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:
- /robot_model_bandwidth_hog/tf
- /i_wanna_communicate_these_few_transforms_to_other_robots/tf
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