Announcing ros_type_introspection: deserialize any ROS Message in C++

General
1

Hi,

I am pleased to announce a new package that focuses on deserialization of ROS Messages when the original type is unknown at compilation time.
This is a common problem in any generic piece of code that should be able to extract information from any rosbag/topic that does exist or will exist.

http://wiki.ros.org/ros_type_introspection

The typical use cases are:

  1. Rosbag importers (the library is partially influenced by https://github.com/bcharrow/matlab_rosbag).
  2. Tools similar to rqt_plot and rqt_bag that can be used with any rosbag and/or ros topic.

Regards

Davide

2

Very cool!

I’m generally in favor of tools with generic interfaces because it means that we can relax the dependencies between packages.

For example, imagine a world where Rviz could leverage leverage/introspection so that instead of writing visualization plugins, Rviz could deduce how to visualize custom message types composed of known visualizable message types.

But I digress. My favorite way to do generic introspection is using metaprogramming on the C++ struct/class definition itself so that the work of iterating over the type is delegated to compile time. However if the ROS type is type-erased then I do think this is not possible and building a runtime representation of the schema is required.

Looking forward to seeing how this is used in PlotJuggler! :slight_smile:

3

the problem that this library is solving can not be solved with meta programming.
Meta programming means that the compiler does computation or code generation during the compilation phase.
ros_type_introspection, on the other hand, has absolutely zero knowledge at compile time of the message it is going to parse, understand and deserialize.
Meta programming MIGHT have been useful to make my code more terse.

you might want to take alook to the tutorials on the ROS wiki. on PlotJuggler it allows me already to open any rosbag and subscribe to any topic.

4

@jackie, by the way, I am afraid that (if I have understood correctly) what you mentioned about the “generic RVIZ” system is technically impossible (this is not a C++ problem, it is an intrinsic one).

When you have a “publisher/writer” that serializes an information and a “subscriber/reader” that receives it, these two pieces of software must agree on the SEMANTIC of the message (the “contract” if you prefer) and of course they must both know how the message was translated/marshalled/serialized into a blob.

A “generic” subscriber has no way, by definition of “generic”, to know in advance the type of the message, only its schema. The schema can give instructions about how to map the information into builtin types (this is what ros_type_introspection does), but it can not “understand” its semantic.

Imagine that you receive a message with this IDL schema

float64  ugfjikh
float64  hjvf
float64  cdse

I know that they are three floating point numbers and an application like PlotJuggler can plot them on three curves sharing the same X axis.
But what should a subscribes like RVIZ do with this data?