A ROS service is a request–response call between nodes — one node asks a question and waits for an answer, the right tool for quick, occasional commands where topics' fire-and-forget streaming doesn't fit.
A ROS service is like a phone call between programs: one asks a question and waits for the answer, then hangs up. It's for quick, occasional requests — "reset the map" — not for continuous data.
Not everything a robot's programs need to say is a continuous stream. Sometimes one node needs to ask another a question and get an answer — "reset the map," "is the gripper open?", "compute this plan." That's a ROS service.
What it is
A service is a request–response interaction. A client node sends a request and waits; a server node receives it, does the work, and sends back a response. It's synchronous and one-to-one — like a phone call, versus a topic's radio broadcast. The service has a name (like /reset_map) and a defined request/response type.
Ask, wait, answer
One question, one answer. The client blocks until the reply arrives — ideal for occasional queries and commands, not continuous data.
When to use which
ROS gives three ways for nodes to interact, and picking correctly is a common judgment call:
Services — quick request/response that finishes fast (a query, a config change, a short computation). The client waits.
Actions — long-running goals that take seconds or minutes, need progress feedback, and can be cancelled (navigate somewhere, execute a trajectory).
The rule of thumb: if it's fast and you need an answer, use a service; if it's slow, use an action; if it's a stream, use a topic.
The caution
Because a service call blocks the client until it returns, calling a slow service from inside a callback can stall a node — a classic source of freezes. Services should do quick work; anything lengthy belongs in an action. This is also why calling a service from within another callback needs care with ROS 2's executor model.
Everyday tools
ros2 service list shows available services, and ros2 service call /reset_map std_srvs/srv/Empty invokes one from the terminal — handy for triggering one-off actions while testing.
Why it matters
Services are the request/response half of ROS communication — the tool for commands and queries that don't fit the streaming model. Knowing when to use a service versus a topic or action is core to designing clean robot software.
