ROS Interfaces

List of ROS interfaces:

• Topics (asynchronous): this interfaces uses a publish/subscribe model, where publishers and subscribers exchange information using messages defined in .msg files.
• Services (synchronous): operates on a request/response model, where service clients send requests to service servers and await a response. the information that is exchanged is called a service and is defined using .srv files, and the interaction is synchronous, requiring both parties to be available during the transaction.
• Actions (asynchronous): Actions extend the request/response model with the addition of feedback and result, enabling long-running tasks with intermediate updates. Action clients and servers communicate using actions defined using .action files.

From Topics vs Services vs Actions - ROS 2 Official Docs ↗ .

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:

• 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:

• 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.

Documentation:

• Topics vs Services vs Actions - ROS 2 Docs ↗ : guidelines about when to use each type of interface.
• Interfaces - ROS 2 Docs ↗
• Interface definition - ROS 2 Design ↗