The data flow is modeled with a pipeline metaphor, where data always flows from a source to a sink. A filter is both source and sink for data, possibly with different data types. For integration with ROS, the library provides a number of subscribers and publishers which act as sources or sinks of the data flow.
While you are free to derive your own classes from the one of the base classes, most programs will want to register a custom callback function for their application logic.
The SimpleUserFilter works almost like a regular ROS callback, but it expects a boolean return value that determines if the data is passed on to subsequent filters in the pipeline (if any), or if processing terminates. You can use this type of filter to consume data at the end of the pipeline, or if you want to remove invalid inputs before further processing occurs.
The UserFilter is more generic and can be used if your filter outputs differ from its inputs. You can implement pretty much any kind of transforming filter.
A third filter UserSource is a simple data source which can be used as callback in third-party code.
As a simple "Hello World" example, consider:
The user-defined filter accepts a
std_msgs::String message with a name as input and composes a new
std_msgs::String message with a personalized greeting as output. Note that each source can have arbitrarily many sinks connected to it, and vice vera, so the simplicity of the three-link chain in this example is by no means a limitation of the library.
Sources and sinks are strongly typed, i.e., each source will only pass on data of a particular type, and each sink will only accept data of a particular type. The compiler will error out if you try to connect incompatible filters. As the strong typing relies on the C++ template mechanism, the error messages can be quite verbose and difficult to parse (looking at you, GCC). It is very much recommended to use the
Output typedefs which are provided by every filter.
All sources and sinks support the grouping of multiple data types, where items of different types are combined and passed on as a unit. This is particularly useful to process messages from distinct topics which belong together conceptually, e.g., the
sensor_msgs::CameraInfo messages from a calibrated camera. N-ary filters can be created, rearranged, and broken up using the Combiner , Divider , and Selector filters.
Generally, the pipeline processing is executed by nested calls to receive and send functions. The library is thread-safe and guarantees basic exception safety, but you are expected to handle your own exceptions in your callbacks. Exceptions which propagate through library code will abort processing for the offending message immediately, even if not all downstream sinks have received the message yet. If there is no upstream user-defined filter that catches the exception, the uncaught exception will eventually terminate the program. The library will detect cycles in the pipeline and abort with a