In our previous ROS 1 basics tutorial, we covered how ROS nodes communicate with each other by publishing and subscribing to message streams on topics.

Another common way nodes can share information with each other is via services. With ROS 1 services, one or many "client" nodes can make requests to a "server" node and wait for its response. These make services great for performing on-demand tasks – like performing on-the-fly computations or simple one-time tasks.

In this tutorial, we'll learn how to build a client and server node in C++, and implement a service for them to pass data to each other.

How do services work?

Unlike topics, which follow a publish-subscribe model to send each other information, services follow a request-response model.

With services, a client node must first call the server in order to send a request. This means that in the server-client mode, nodes do not use a communication stream until it’s absolutely needed, preventing unnecessary bandwidth usage. Then, the client node must wait for a response from the server (or until a timeout is reached). For this reason, services can confirm communication between nodes.

Services consist of two parts - a request and a response. Each part can be empty or contain as many data fields that you want to share between nodes.

To define a service, you must create a .srv file in your ROS 1 package’s srv directory that contains both those components:



Let’s start by exploring three different service definitions in the std\_srvs package:

Empty.srv – Empty request and response. The only data that is passed from client to server is the call itself.

Trigger.srv – Empty request and a response with success and message fields. This allows the server to send more information to the client.

SetBool.srv – Request with data field and response with success and message fields.

The more fields a service contains, the more information the client and server can exchange with each other.

When should I use services?

Let’s suppose you want to create a routine check for your robot – for example, you may want to verify at start-up that your robot's servo motors are all working properly.

If you were to create a publisher for this task, your node could publish its check results before a corresponding subscriber becomes available. As a result, you'd miss the check results and be left in the dark about the status of your motors.

But if you were to create a service instead, your server node wouldn't broadcast any data before it is explicitly requested by a client node. Using a service ensures that you do not miss crucial information due to inopportune timing.

In the service scenario, the client node could be a diagnostics node that gathers robot state data at start-up. The server node could be a motor node that controls the robot’s servo motors. If all goes well, and the actuators are working properly, the server node would deliver a response saying that all checks passed. If any motors encountered an issue, however, the response would raise an alarm.

Service request and response
The client will wait for a response within a specified timeout period.

A ROS 1 service in action

Now that we’ve discussed how when you might use ROS services, let’s dive into some actual code.

Let's use the Trigger.srv we saw before. Remember that this service definition contains no field in the request. The client is not sending any data to the server when it makes this request - it is just a trigger. The server, however, will respond with success and message fields.

We’ll begin by creating our own ROS 1 package. Navigate to the src folder of your ros1\_ws and create a package named srv\_client\_checks:



Writing a server node

Let's start out with our server motor\_node, which will run the necessary check on the servo motors.

Go to the src folder of your new package and create a file named motor\_node.cpp:



Define two functions: moveMotorToMinAndMax and doChecks.

moveMotorToMinAndMax will simulate the motors moving to their maximum and minimum positions. If the motor successfully reaches both limits, the function will return true; otherwise, it will return false.



The doChecks server callback receives two inputs (a request and response) and will run when the server is activated by a client. It iterates over all available motors to perform the moveMotorToMinAndMax check on each one, then sends back a response:



Finally, we create a main function as our entrypoint:



Writing a client node

Now that we have a server node, let's move on to the client node that will request a response from it.

Create a diagnostics\_node.cpp file in your package's src folder, and include the following libraries:



Let's start with our main function:



Next, let’s create a request that the client can send to the server using the Trigger.srv service:



Before we send the request, let's make sure the server is active – otherwise, our request will be lost. The function wait\_for\_service() requires a timeout, which is the maximum time a client will wait for a response.



Once the server is on, the program will continue and send a request:



If client.call(srv\_call) returns true, we know that the server has responded correctly, and we can process that response. Otherwise, we'll get an error message telling us that we failed to call the "checks" service.

Compiling the package

Add the executables to your compilation file, and install them in your path, so that the rosrun command can find them.

In the CMakeList.txt file, make sure that you've the following:



Return to the root folder of your workspace to compile with your new nodes:



Run your nodes

We can finally run both our client and server nodes to see if they can communicate with each other properly!

First, start up your ROS master in a terminal window:



You will need two other terminal windows – remember to source install/setup.bash in each one before running any ROS 1 command:



The first terminal will contain the client diagnostics\_node:



This node will wait for motor\_node to appear before requesting the checks.

Next, run the server motor\_node to execute the checks:



When motor\_node executes and the server activates, it performs its checks. In this case, a warning shows because we don't have any motors – there is no possible way for the checks to succeed!

Running both nodes
Left: Client diagnostics\_node. Right: Server motor\_node.

You've now created a server-client communication that checks your actuators and sensors during start-up, making sure that everything is working properly before continuing.

Continue playing around with running your nodes to see how they behave. For example, what would you expect to happen if you run the server node before the client?

Keep learning!

We hope you enjoyed this tutorial and now have a better understand of how you can use ROS 1 services in your own robotics project. Continue learning with our ROS tutorials and other articles on our blog.

As always, feel free to check our docs or reach out to us directly in our Slack community to learn how our tools can help you accelerate your ROS development!


There are several different ways that ROS 2 nodes can share information with each other. They can publish an ongoing stream of data via topics, or initiate one-off requests via services.

Actions are a final way for ROS nodes to communicate with each other. They combine the best of both worlds, using both open-ended data streams and discrete requests to execute long-running tasks.

In this tutorial, we’ll discuss how ROS actions work, when to use them, and how to implement a simple action client and server in Python.

How do ROS 2 actions work?

With topics, nodes follow a publisher-subscriber model – a node publishes messages on a topic, while other nodes subscribe to that topic. Services, on the other hand, follow a request-response (RPC) model – a client node makes a request to a server node, then waits for an asynchronous response.

Under the hood, ROS actions are built on top of both topics and services. They maintain open-ended streams of communication (like topics) that can be initiated or canceled on request (like services).

At a high level, a client node initiates an action by sending a goal as a service request to a server node (step 1 in diagram below). Once that server node acknowledges the goal with a service response, it will start publishing feedback, or updates on its progress towards that goal, on a topic (step 2). Meanwhile, the client node makes a second service request for the action’s result (step 3). Once the goal succeeds or fails, the server sends back a service response containing the result.

ROS actions

How can we use ROS 2 actions?

Their three-part architecture – goal, feedback, and result – makes ROS actions especially well-suited for long-running tasks. It’s no surprise, then, that actions are most often used by robots for navigation tasks.

If a fleet operator wanted to send a warehouse AMR to a particular aisle a few minutes away, for example, they can initiate a ROS action with that destination as the goal. While on its journey, the robot could broadcast feedback back to the operator about how far it has traveled along its designated route.

If requirements change, and the operator decides to send the AMR to a different aisle, they have the option to cancel the first action and initiate a new one to reroute the robot to a different destination. Otherwise, if the robot successfully reaches its destination, it sends a final confirmation back to the operator, confirming its arrival.

Defining an action

Now that we know how actions work, and when they can be used, let's write some code!

For this exercise, let's create an action that alerts a warehouse robot when it's time for it to start its shift. The action should start counting down from a given number, broadcast updates as it progresses, then finally announce when it’s reached zero.

Actions are defined in .action files, with 3 sections separated by ---:



In a ROS 2 package, create an action/ directory with a Countdown.action file. Let’s include a starting\_num for the countdown in the request, the current\_num in the feedback, and confirmation that the countdown is\_finished in the result:



Before we can use this action, we have to pass the definition to the rosidl code generation pipeline. Add the following lines to your CMakeLists.txt file, before the ament\_package() line:



We should also add the required dependencies to our package.xml:



You can now navigate to the root of your package, and build it with your action definition:



Source your workspace, then check that the action built successfully:



Writing an action server

Let’s write an action server that counts down from our Countdown action request’s starting\_num.

Create a countdown\_server.py file in your package and import the following packages:



Create a CountdownServer class as a subclass of the Node class, which will be initialized as a node named "countdown\_server". Then, create an action server that specifies the node for the action client to attach to (self), the action type (Countdown), the action name ("countdown"), and a callback function for handling goals from the client (execute\_callback):



Next, define the execute\_callback function as one that logs a helpful message ("Starting countdown…"), indicates that the goal succeeded, and then returns a result:



Finally, let’s spin up an instance of this CountdownServer class:



In a Terminal window, run your action server:



In another window, use ros2 action to send a goal:



In the first window, you should see "Starting countdown…", followed by the status SUCCEEDED.

Now that we’ve verified our server is running, let’s actually count down from our goal’s starting\_num:



If you restart the action server and send another goal using the --feedback flag, you’ll now see a printout of the feedback logs and the goal result (true).



Writing an action client

Now that we have a server working, let’s write the client that will initiate the request to your server.

Create a new countdown\_client.py file, and import the following packages:



Once again, we create a class (CountdownClient ) as a subclass of the Node class, which will be initialized as a node named "countdown\_client". It should contain an action client that specifies the node for the client to attach to (self), the action type (Countdown), and the action name ("countdown"):



As we discussed, the primary function of a client is to send a goal to the server:



Once the goal is acknowledged by the server, we want to be able to access whether it was accepted and whether it reached a successful result:



Finally, initialize ROS and spin up the client node:



In separate Terminal windows, run your action server and action client:



In the server window, you should see feedback messages printing as the server executes the goal:



In the client window, you should see messages about the goal’s status, the ongoing feedback, and eventually the final result.

You've created your first working ROS action client and server!

Summary

By leveraging the strengths of both topics and services, ROS 2 actions are able to set goals, make progress on those goals, and broadcast when they’ve succeeded.

We hope this tutorial helped you get a better understanding of how you might use ROS actions in the larger scheme of your robot’s architecture. For a reference to all the code covered in this post, check out our ros2-actions-tutorial GitHub repo here.

As always, feel free to reach out to the Foxglove team in our Slack community to ask questions, give us feedback, and request a topic for the next tutorial!


In our previous ROS 2 basics tutorial, we covered how ROS nodes communicate with each other by publishing and subscribing to message streams on topics.

Another common way nodes can share information with each other is via services. With ROS 2 services, one or many "client" nodes can make requests to a "server" node and wait for its response. These make services great for performing on-demand tasks – like performing on-the-fly computations or simple one-time tasks.

In this tutorial, we'll learn how to build a client and server node in C++, and implement a service for them to pass data to each other.

How do services work?

Unlike topics, which follow a publish-subscribe model to send each other information, services follow a request-response model.

With services, a client node must first call the server in order to send a request. This means that in the server-client mode, nodes do not use a communication stream until it’s absolutely needed, preventing unnecessary bandwidth usage. Then, the client node must wait for a response from the server (or until a timeout is reached). For this reason, services can confirm communication between nodes.

Services consist of two parts - a request and a response. Each part can be empty or contain as many data fields that you want to share between nodes.

To define a service, you must create a .srv file in your ROS 2 package’s srv directory that contains both those components:



Let’s start by exploring three different service definitions in the std\_srvs package:

Empty.srv – Empty request and response. The only data that is passed from client to server is the call itself.

Trigger.srv – Empty request and a response with success and message fields. This allows the server to send more information to the client.

SetBool.srv – Request with data field and response with success and message fields.

The more fields a service contains, the more information the client and server can exchange with each other.

When should I use services?

Let’s suppose you want to create a routine check for your robot – for example, you may want to verify at start-up that your robot's servo motors are all working properly.

If you were to create a publisher for this task, your node could publish its check results before a corresponding subscriber becomes available. As a result, you'd miss the check results and be left in the dark about the status of your motors.

But if you were to create a service instead, your server node wouldn't broadcast any data before it is explicitly requested by a client node. Using a service ensures that you do not miss crucial information due to inopportune timing.

In the service scenario, the client node could be a diagnostics node that gathers robot state data at start-up. The server node could be a motor node that controls the robot’s servo motors. If all goes well, and the actuators are working properly, the server node would deliver a response saying that all checks passed. If any motors encountered an issue, however, the response would raise an alarm.

Service request and response
The client will wait for a response within a specified timeout period.

A ROS 2 service in action

Now that we’ve discussed how when you might use ROS services, let’s dive into some actual code.

Let's use the Trigger.srv we saw before. Remember that this service definition contains no field in the request. The client is not sending any data to the server when it makes this request - it is just a trigger. The server, however, will respond with success and message fields.

We’ll begin by creating our own ROS 2 package. Navigate to the src folder of your ros2\_ws and create a package named srv\_client\_checks:



Writing a server node

Let's start out with our server motor\_node, which will run the necessary check on the servo motors.

Go to the src folder of your new package and create a file named motor\_node.cpp:



Define two functions: moveMotorToMinAndMax and doChecks.

moveMotorToMinAndMax will simulate the motors moving to their maximum and minimum positions. If the motor successfully reaches both limits, the function will return true; otherwise, it will return false.



The doChecks server callback receives two inputs (a request and response) and will run when the server is activated by a client. It iterates over all available motors to perform the moveMotorToMinAndMax check on each one, then sends back a response:



Finally, we create a main function as our entrypoint:



Writing a client node

Now that we have a server node, let's move on to the client node that will request a response from it.

Create a diagnostics\_node.cpp file in your package's src folder, and include the following libraries:



Let's start with our main function:



Next, let’s create a request that the client can send to the server using the Trigger.srv service:



Before we send the request, let's make sure the server is active – otherwise, our request will be lost. The function wait\_for\_service() requires a timeout, which is the maximum time a client will wait for a response.



Once the server is on, the program will exit the while loop, send the request, and spin the node until the future is complete (i.e. the client receives a response from the server).

If spin\_until\_future\_complete returns a SUCCESS, we know that the server has responded correctly, and we can process that response. If the return value is not SUCCESS, we can assume there was a problem with reaching the server:



Compiling the package

Add the executables to your compilation file, and install them in your path, so that the ros2 run command can find them.

In the CMakeList.txt file, make sure that you've the following:



Return to the root folder of your workspace to compile with your new nodes:



Run your nodes

We can finally run both our client and server nodes to see if they can communicate with each other properly!

You will need two terminal windows – remember to source install/setup.bash in each one before running any ROS 2 command:



The first terminal will contain the client diagnostics\_node:



This node will wait for motor\_node to appear before requesting the checks.

Next, run the server motor\_node to execute the checks:



When motor\_node executes and the server activates, it performs its checks. In this case, a warning shows because we don't have any motors – there is no possible way for the checks to succeed!

Running both nodes
Left: Client diagnostics\_node. Right: Server motor\_node.

You've now created a server-client communication that checks your actuators and sensors during start-up, making sure that everything is working properly before continuing.

Continue playing around with running your nodes to see how they behave. For example, what would you expect to happen if you run the server node before the client?

Keep learning!

We hope you enjoyed this tutorial and now have a better understand of how you can use ROS 2 services in your own robotics project. Continue learning with our ROS tutorials and other articles on our blog.

As always, feel free to check our docs or reach out to us directly in our Slack community to learn how our tools can help you accelerate your ROS development!


Manage your robotics data with Foxglove Data Platform

Scalable data management for fast-moving robotics teams

Manage your team settings and data through a convenient web UI.

Analyze meaningful segments of your data.

Use our public API endpoints or CLI to quickly retrieve the data that you're interested in.

Ready to get started?Upgrade to a paid plan today.