Services and Actions
Imagine you are ordering a pizza for delivery while your friend waits for the confirmation receipt. You provide your specific address and order details, then you wait for the shop to signal that your food is on the way. This simple exchange of requests and results happens constantly within complex robotic systems. In the world of ROS 2, developers use specific patterns to handle these direct interactions between different parts of a machine. These methods ensure that every command sent by a controller gets a clear response back.
Understanding Request and Response Patterns
When you need a robot to perform a task with a definite start and finish, you use a Service. Think of a service like a phone call where you ask a question and wait for an answer. One node sends a request, and another node processes that request before sending a reply. This structure is perfect for tasks like opening a gripper or moving to a specific coordinate. Because the system waits for the result, it ensures that the robot knows if the task succeeded. Without this confirmation, the system might try to move forward before the robot is ready.
Key term: Service — a synchronous communication pattern that allows one node to request a specific action from another node and receive a response once the task is finished.
Services are ideal for simple tasks that happen instantly or very quickly. If you ask a robot to calculate its current battery level, the service pattern works perfectly. The request is sent, the sensor reads the data, and the answer returns immediately. However, services are not built for long tasks that take several seconds to complete. If a robot must navigate across a large room, waiting for a single service response would lock up the entire system. In these cases, developers rely on more advanced tools that provide feedback during the process.
Managing Complex Actions Over Time
When a task requires significant time to complete, you should use an Action instead of a service. Actions are like a long-term project where you receive updates as the work progresses toward completion. You initiate the action, receive periodic status reports, and finally get a result when the job ends. This prevents the system from freezing while the robot performs a slow maneuver. Actions allow the robot to handle multiple states, such as moving, pausing, or canceling the task entirely.
To better understand how these two communication patterns differ in practice, consider the following comparison of their primary functional traits:
| Feature | Service Pattern | Action Pattern |
|---|---|---|
| Duration | Instant or fast | Long or complex |
| Feedback | Single response | Periodic updates |
| Control | Request-reply | Cancelable tasks |
| Usage | Data retrieval | Motion execution |
These patterns provide the backbone for how different hardware components share information and coordinate their physical movements. When you use an action, you can monitor the progress of a robot arm as it reaches for an object. If an obstacle appears, the action allows you to send a cancel command to stop the motion. This level of control is vital for safety in environments where robots interact with humans. By choosing the right tool for the job, you make the robot more reliable and easier to manage during complex operations.
When you design a robot, you must decide if your command needs a simple answer or a detailed progress report. A service is great for quick status checks like reading a sensor value. An action is necessary for complex tasks like path planning or long-distance travel. By mastering these two distinct communication styles, you gain total control over the robot's behavior. This foundation allows you to build sophisticated machines that handle many different tasks at the same time without losing track of the current progress.
Services provide immediate request-response cycles for simple data, while actions manage long-running tasks by providing continuous feedback and control options.
The next Station introduces Parameter Management, which determines how variables and settings are stored and updated within the robot.