Home

#Ros message introspection

Or... "If you don't know why you need it, probably you don't need it".

This simple library extracts information from a ROS Message, even when its type is unknown at compilation time.

Have you ever wanted to build an app that can subscribe to any topic and extract its content, or can read data from any rosbag? What if the topic and/or the bag contains user defined ROS types ignored at compilation time?

The common solution in the ROS ecosystem is to use Python, that provides the needed introspection. Tools, for instance, like rqt_plot and rqt_bag took this approach. This library implements a C++ alternative.

The library is composed of three main modules:

• Parser: it performs introspection of a Ros Message using the schema stored in ros::message_traits::Definition. Read more.

• Deserializer:using the schema built by the parsed, it can extract the actual values from a raw message. Read more.

• Renamer: last but not least, the library offers as well an easy way to remap/rename the data using a simple set of rules. This can be very handy in multiple scenarios that are very common in ROS. Read more.

This library is particularly useful to extract data from two type-erasing classes provided by ROS itself:

1. topic_tools::ShapeShifter: a type used to subscribe to any topic, regardless of the original type.

2. rosbag::MessageInstance: the generic type commonly used to read data from a ROS bag.

#Some background The ROS Message Types can be described as a Interface Describtion Language. This approach is very well known and commonly used on the web and in distributed systems in general.

A rosmsg is defined by the user; an "IDL compiler", i.e. gencpp, reads this schema and generates an header file that contains the source code that the user shall be included in his/her applications. The inclusion of this header file is needed on both the publisher and the subscriber sides.

This approach provides strong and type-safe contracts between the producer and the consumer of the message and, additionally, is needed to implements a fast serialization / deserialization mechanism.

The only "problem" is that in very few use cases (for instance if you want to build a plugin to load ROS bags in MATLAB) you don't know in advance which ROS Messages you will need to read. Therefore, you won't be able to include the necessary header files.