I run a Gazebo server on one machine and try to call a Gazebo service from a different machine in the same network.

There is a bidirectional communication between the two machines (i.e. ping works from both sides).

Gazebo transport's discovery mechanism seems to work, because I receive the topics and services on the second machine :

$ gz service -l
... (other topics)

However, when I try to call a service, it fails :

$ gz service -s /world/multicopter/list_parameters --reqtype gz.msgs.Empty --reptype gz.msgs.ParameterDeclarations --timeout 2000 --req ''
Service call timed out

Questions: Has someone already tried this? Do you have any idea why the service request times out?


  • the GZ_PARTITION is set to similar value in both machines
  • Topics are detected (gz topic -l outputs the list of topics) but not received (gz topic -e -t /foo outputs nothing)

2 Answers 2


I managed to solve my issue !

gz-transport answers service requests using TCP (unlike the discovery, which uses UDP multicast).

This means that gz-transport has to choose a network interface from your computer (I think it is done here), but you can force this choice by setting GZ_IP.

In my case, gazebo was using an interface that had no route toward the "client" machine. The two machines communicate through the network (respectively and

To solve it, I simply set the interface I want to use on each machine :
Machine 1 :

export GZ_IP=

Machine 2 :

export GZ_IP=

tip : Set GZ_VERBOSE=1 to receive debug information and see which interface is being used by Gazebo ! :)


gz-transport has the notion of partitions which allows you to isolate some topics/services from others. One of the constituents of the partition name is the host name as mentioned in https://gazebosim.org/api/transport/12/nodestopics.html#autotoc_md23. Since you're trying to communicate across different machines, you'll need to set the partition name to be identical in both hosts. You'd do this by setting the GZ_PARTITION environment variable.

  • $\begingroup$ Thank you for your answer @azeey ! I already set the GZ_PARTITION env variable to the same value on both machines, as it is used in the discovery mechanism also, and I correctly receive existing topics and services on the "client" machine (gz service -l works fine). Even in the same Gazebo partition it appears the service request fails. My call is that the "discovery" and "service answer" packets are different in term of networking, but I can't find the difference. $\endgroup$ Jun 13, 2023 at 8:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.