\page messages Messages
Next Tutorial: \ref services Previous Tutorial: \ref nodestopics
In this tutorial, we are going to create two nodes that are going to communicate via messages. One node will be a publisher that generates the information, whereas the other node will be the subscriber consuming the information. Our nodes will be running on different processes within the same machine.
mkdir ~/gz_transport_tutorial
cd ~/gz_transport_tutorial
Download the publisher.cc file within the gz_transport_tutorial
folder and open it with your favorite editor:
\snippet example/publisher.cc complete
#include <gz/msgs.hh>
#include <gz/transport.hh>
The line #include <gz/transport.hh> contains all the Gazebo
Transport headers for using the transport library.
The next line includes the generated protobuf code that we are going to use
for our messages. We are going to publish StringMsg type protobuf messages.
// Create a transport node and advertise a topic.
gz::transport::Node node;
std::string topic = "/foo";
auto pub = node.Advertise<gz::msgs::StringMsg>(topic);
if (!pub)
{
std::cerr << "Error advertising topic [" << topic << "]" << std::endl;
return -1;
}
First of all we declare a Node that will offer some of the transport functionality. In our case, we are interested in publishing topic updates, so the first step is to announce our topic name and its type. Once a topic name is advertised, we can start publishing periodic messages using the publisher object.
// Prepare the message.
gz::msgs::StringMsg msg;
msg.set_data("HELLO");
// Publish messages at 1Hz.
while (!g_terminatePub)
{
if (!pub.Publish(msg))
break;
std::cout << "Publishing hello on topic [" << topic << "]" << std::endl;
std::this_thread::sleep_for(std::chrono::milliseconds(1000));
}
In this section of the code we create a protobuf message and fill it with content. Next, we iterate in a loop that publishes one message every second. The method Publish() sends a message to all the subscribers.
Download the subscriber.cc
file into the gz_transport_tutorial folder and open it with your favorite editor:
\snippet example/subscriber.cc complete
//////////////////////////////////////////////////
/// brief Function called each time a topic update is received.
void cb(const gz::msgs::StringMsg &_msg)
{
std::cout << "Msg: " << _msg.data() << std::endl << std::endl;
}
We need to register a function callback that will execute every time we receive
a new topic update. The signature of the callback is always similar to the one
shown in this example with the only exception of the protobuf message type.
You should create a function callback with the appropriate protobuf type
depending on the type of the topic advertised. In our case, we know that topic
/foo will contain a Protobuf StringMsg type.
gz::transport::Node node;
std::string topic = "/foo";
// Subscribe to a topic by registering a callback.
if (!node.Subscribe(topic, cb))
{
std::cerr << "Error subscribing to topic [" << topic << "]" << std::endl;
return -1;
}
After the node creation, the method Subscribe() allows you to subscribe to a
given topic name by specifying your subscription callback function.
// Zzzzzz.
gz::transport::waitForShutdown();
If you don't have any other tasks to do besides waiting for incoming messages,
you can use the call waitForShutdown() that will block your current thread
until you hit CTRL-C. Note that this function captures the SIGINT and
SIGTERM signals.
Download the CMakeLists.txt file within the gz_transport_tutorial folder.
Once you have all your files, go ahead and create a build/ directory within
the gz_transport_tutorial directory.
mkdir build
cd build
Run cmake and build the code.
# Linux and MacOS
cmake ..
make publisher subscriber
# Windows
cmake --build . --config Release
Open two new terminals and from your build/ directory run the executables.
From terminal 1:
# Linux and MacOS
./publisher
# Windows
.\Release\publisher.exe
From terminal 2:
# Linux and MacOS
./subscriber
# Windows
.\Release\subscriber.exe
In your subscriber terminal, you should expect an output similar to this one, showing that your subscriber is receiving the topic updates:
$ ./subscriber
Msg: HELLO
Msg: HELLO
Msg: HELLO
Msg: HELLO
Msg: HELLO
We can specify some options before we publish the messages. One such option is to specify the number of messages published per topic per second. It is optional to use but it can be handy in situations like when we want to control the rate of messages published per topic.
We can declare the throttling option using the following code :
// Create a transport node and advertise a topic with throttling enabled.
gz::transport::Node node;
std::string topic = "/foo";
// Setting the throttling option
gz::transport::AdvertiseMessageOptions opts;
opts.SetMsgsPerSec(1u);
auto pub = node.Advertise<gz::msgs::StringMsg>(topic, opts);
if (!pub)
{
std::cerr << "Error advertising topic [" << topic << "]" << std::endl;
return -1;
}
gz::transport::AdvertiseMessageOptions opts;
opts.SetMsgsPerSec(1u);
In this section of code, we declare an AdvertiseMessageOptions object and use it to pass message rate as an argument to SetMsgsPerSec() method. In our case, the object name is opts and the message rate specified is 1 msg/sec.
auto pub = node.Advertise<gz::msgs::StringMsg>(topic, opts);
Next, we advertise the topic with message throttling enabled. To do it, we pass opts as an argument to the Advertise() method.
A similar option is also available for the Subscriber node which enables it to control the rate of incoming messages from a specific topic. While subscribing to a topic, we can use this option to control the number of messages received per second from that particular topic.
We can declare the throttling option using the following code :
// Create a transport node and subscribe to a topic with throttling enabled.
gz::transport::Node node;
std::string topic = "/foo";
gz::transport::SubscribeOptions opts;
opts.SetMsgsPerSec(1u);
node.Subscribe(topic, cb, opts);
gz::transport::SubscribeOptions opts;
opts.SetMsgsPerSec(1u);
node.Subscribe(topic, cb, opts);
In this section of code, we declare a SubscribeOptions object and use it to pass message rate as an argument to the SetMsgsPerSec() method. In our case, the object name is opts and the message rate specified is 1 msg/sec. Then, we subscribe to the topic using the Subscribe() method with opts passed as an argument to it.
##Generic subscribers
As you have seen in the examples so far, the callbacks used by the
subscribers contain a specific protobuf parameter, such as
gz::msgs::StringMsg. As the name of this section suggests, it is also
possible to create a generic subscriber callback that can receive messages of
different types. This use case might be interesting if you are building a bridge
between Gazebo Transport and another protocol or if you want to just print the
content of a generic protobuf message using DebugString(), among other use
cases.
Download the subscriber_generic.cc file within the gz_transport_tutorial folder and open it with your favorite editor:
#include <google/protobuf/message.h>
#include <iostream>
#include <string>
#include <gz/transport.hh>
//////////////////////////////////////////////////
/// brief Function called each time a topic update is received.
/// Note that this callback uses the generic signature, hence it may receive
/// messages with different types.
void cb(const google::protobuf::Message &_msg,
const gz::transport::MessageInfo &_info)
{
std::cout << "Topic: [" << _info.Topic() << "]" << std::endl;
std::cout << _msg.DebugString() << std::endl;
}
//////////////////////////////////////////////////
int main(int argc, char **argv)
{
gz::transport::Node node;
std::string topic = "/foo";
// Subscribe to a topic by registering a callback.
if (!node.Subscribe(topic, cb))
{
std::cerr << "Error subscribing to topic [" << topic << "]" << std::endl;
return -1;
}
// Zzzzzz.
gz::transport::waitForShutdown();
return 0;
}
//////////////////////////////////////////////////
/// brief Function called each time a topic update is received.
/// Note that this callback uses the generic signature, hence it may receive
/// messages with different types.
void cb(const google::protobuf::Message &_msg,
const gz::transport::MessageInfo &_info)
{
std::cout << "Topic: [" << _info.Topic() << "]" << std::endl;
std::cout << _msg.DebugString() << std::endl;
}
Here, we use the generic callback function signature. Note the use of
google::protobuf::Message as the message type in the subscription callback
function cb(). It enables us to receive topic updates with different message
types, such as Int32 or String from the subscribed topic.
Furthermore, we don't need to worry about the type of the topic advertised while
specifying the callback function. The parameter
gz::transport::MessageInfo &_info provides some information about the
message received (e.g.: the topic name).
//////////////////////////////////////////////////
int main(int argc, char **argv)
{
gz::transport::Node node;
std::string topic = "/foo";
// Subscribe to a topic by registering a callback.
if (!node.Subscribe(topic, cb))
{
std::cerr << "Error subscribing to topic [" << topic << "]" << std::endl;
return -1;
}
// Zzzzzz.
gz::transport::waitForShutdown();
return 0;
}
Similar to the previous examples, we use the Subscribe() function to
subscribe to a given topic name by specifying the callback function. In our
example, the topic name subscribed is /foo.
Follow the next instructions to compile and run the generic subscriber example:
Run cmake and build the example:
cd build
# Linux and MacOS
cmake ..
make subscriber_generic
# Windows
cmake --build . --config Release
From terminal 1:
# Linux and MacOS
./publisher
# Windows
.\Release\publisher.exe
From terminal 2:
# Linux and MacOS
./subscriber_generic
# Windows
.\Release\subscriber_generic.exe
We use Gazebo Msgs in most of our examples and tests. This decision was made just for convenience but Gazebo Transport supports the use of Protobuf messages directly. The most common problem with custom Protobuf messages is often the integration of the message generation into the build system of your project. Next, you can find an example of a publisher and subscriber using a custom Protobuf message integrated with CMake.
Download the publisher_custom_msg.cc
and the subscriber_custom_msg.cc
files within the gz_transport_tutorial. Then, create a msgs folder and
download the stringmsg.proto
and the CMakeLists.txt
files within the msgs folder. Finally, we'll need the main CMakeLists.txt
file. You should have this file from the previous examples. Otherwise,
download and place it within the gz_transport_tutorial folder.
There's nothing new to show in the publisher_custom_msg.cc or
subscriber_custom_msg.cc besides the use of your custom Protobuf message
instead of Gazebo Msgs. The only relevant parts are in the CMakeLists.txt
files.
# Message generation. Only required when using custom Protobuf messages.
find_package(Protobuf REQUIRED)
add_subdirectory(msgs)
set_source_files_properties(${PROTO_SRC} ${PROTO_HEADER}
PROPERTIES GENERATED TRUE)
include_directories(${CMAKE_BINARY_DIR})
This is how we find the Protobuf CMake config file, to make sure that the macro for Protobuf message generation is available. We also let CMake know that there is a new subdirectory to inspect containing our custom messages.
if (EXISTS "${CMAKE_SOURCE_DIR}/publisher_custom_msg.cc")
add_executable(publisher_custom_msg publisher_custom_msg.cc)
target_link_libraries(publisher_custom_msg
${GZ-TRANSPORT_LIBRARIES}
${PROTO_SRC}
)
add_dependencies(publisher_custom_msg protobuf_compilation)
endif()
if (EXISTS "${CMAKE_SOURCE_DIR}/subscriber_custom_msg.cc")
add_executable(subscriber_custom_msg subscriber_custom_msg.cc)
target_link_libraries(subscriber_custom_msg
${GZ-TRANSPORT_LIBRARIES}
${PROTO_SRC}
)
add_dependencies(subscriber_custom_msg protobuf_compilation)
endif()
In the previous snippet we can see how the binaries are generated. The relevant
part is to add a new dependency. We're telling CMake that these two
binaries depend on the protobuf_compilation target. This will trigger the
recompilation of the binaries if there is any change in our Protobuf messages.
Also, we have to link our binaries with the generated Protobuf messages. The
list of generated messages are contained in the ${PROTO_SRC} variable.
Finally, this is the content of the msgs/CMakeLists.txt file:
PROTOBUF_GENERATE_CPP(PROTO_SRC PROTO_HEADER
stringmsg.proto
)
# Variables needed to propagate through modules
# If more than one layer of cmake use CACHE INTERNAL ...
set(PROTOBUF_INCLUDE_DIRS ${PROTOBUF_INCLUDE_DIRS} PARENT_SCOPE)
set(PROTOBUF_LIBRARIES ${PROTOBUF_LIBRARIES} PARENT_SCOPE)
set(PROTO_SRC ${PROTO_SRC} PARENT_SCOPE)
set(PROTO_HEADER ${PROTO_HEADER} PARENT_SCOPE)
add_custom_target(protobuf_compilation DEPENDS ${PROTO_SRC})
The macro PROTOBUF_GENERATE_CPP will use protoc to generate the .pb.h
and .pb.cc files from your .proto files. Follow the next instructions to
compile and run the generic subscriber example:
Run cmake and build the example:
cd build
# Linux and MacOS
cmake ..
make
# Windows
cmake --build . --config Release
From terminal 1:
# Linux and MacOS
./publisher_custom_msg
# Windows
.\Release\publisher_custom_msg.exe
From terminal 2:
# Linux and MacOS
./subscriber_custom_msg
# Windows
.\Release\subscriber_custom_msg.exe
It's possible to set some global node options that will affect both publishers
and subscribers. One of these options is topic remapping. A topic remap
consists of a pair of topic names. The first name is the original topic name to
be replaced. The second name is the new topic name to use instead. As an example,
imagine that you recorded a collection of messages published over topic /foo.
Maybe in the future, you want to play back the log file but remapping the topic
/foo to /bar. This way, all messages will be published over the /bar
topic without having to modify the publisher and create a new log.
We can declare the topic remapping option using the following code:
// Create a transport node and remap a topic.
gz::transport::NodeOptions nodeOptions;
nodeOptions.AddTopicRemap("/foo", "/bar");
gz::transport::Node node(nodeOptions);
std::string topic = "/foo";
You can modify any of the publisher examples to add this option.
From terminal 1:
# Linux and MacOS
./publisher
# Windows
.\Release\publisher.exe
From terminal 2 (requires Gazebo Tools):
gz topic --echo -t /bar
And you should receive all the messages coming in terminal 2.
The command gz log playback also supports the notion of topic remapping. Run
gz log playback -h in your terminal for further details (requires Gazebo Tools).