Available Now
Book a demo and get early access. Free trial!
In robotics, sometimes a robot needs to ask before it acts.
That’s where ROS 2 services come in — they enable request/response interactions between nodes. Unlike topics, which stream data continuously, services are used when you want something more structured and deliberate: “Hey, can you reset the counter?” or “Should I turn on this LED?”
Whether you’re toggling a sensor, resetting a simulation state, or commanding a one-time action, services give your robot a synchronous way to make decisions.
In ROS 2, services provide a synchronous communication mechanism between nodes — ideal for tasks that require explicit invocation and guaranteed response handling. Unlike topics, which implement a pub/sub model for continuous data streams, services follow a strict client/server paradigm where a node sends a request and blocks until it receives a response.
This design makes services a critical tool for:
In high-fidelity simulation environments like Isaac Sim, services are particularly valuable for synchronizing simulation control with ROS-based test logic — allowing you to programmatically reset scenes, inject dynamic events, or toggle components with surgical precision.
A ROS 2 service consists of:
/reset_counter
){int: 0}
){success: true}
)One node runs a service server that waits for requests. Another node runs a service client that sends them.
You can define your own .srv
files with custom request and response types — or reuse common ones like SetBool
or Trigger
.
Services are perfect when you want to:
You can embed custom USD prims and metadata that respond to ROS 2 service calls. This creates a reproducible loop: bag replay → ROS service → USD state change → test results → bag record.
Book a demo and get early access. Free trial!